VISUAL vs. EDITOR - qual a diferença?


182

Geralmente, defino as variáveis ​​de ambiente VISUALe EDITORda mesma maneira, mas qual é a diferença? Por que eu os definiria de maneira diferente? Ao desenvolver aplicativos, por que devo optar por analisar VISUALantes EDITORou vice-versa?

Respostas:


145

O EDITOReditor deve poder trabalhar sem o uso da funcionalidade "avançada" do terminal (como antigo edou exmodo de vi). Foi utilizado em terminais de teletipo.

Um VISUALeditor pode ser um editor de tela cheia como viou emacs.

Por exemplo, se você chamar um editor por meio do bash (usando C-x C-e), o bash tentará o primeiro VISUALeditor e, em seguida, se VISUALfalhar (porque o terminal não suporta um editor em tela cheia), ele tenta EDITOR.

Atualmente, você pode deixar a EDITORconfiguração ou configurá-la como vi -e.


9
A maioria dos aplicativos trata $VISUALcomo um trecho de shell ao qual anexa o nome do arquivo (entre aspas), mas alguns o tratam como o nome de um executável no qual eles podem ou não pesquisar $PATH. Portanto, é melhor definir VISUAL(e EDITOR) o caminho completo para um executável (que pode ser um script de wrapper, se você quiser, por exemplo, opções).
Gilles

4
Nos tempos modernos, ede similares não são muito populares, então acredito que não há problema em ignorar VISUALe usar EDITOR.
Pavel Šimerda 30/03

13
Obrigado pela dica sobre C-x C-eno bash. Muito conveniente.
Mndrix

5
@ PavelŠimerda, apenas a configuração EDITORnão é suficiente, por exemplo, gitno Ubuntu 12.04. Sem VISUALser definido, gitignora EDITORe apenas usa nano(o compilado por padrão, eu acho).
maxschlepzig

5
@ PavelŠimerda Não faz sentido, mas é a convenção. O EDITOR costumava ser para editores baseados em instruções, como ed. Quando editores com GUIs surgiram - e por GUI, quero dizer CLI GUI (vim, emacs, etc .-- think ncurses), não GUI de ambiente de desktop - o processo de edição mudou drasticamente, de modo que surgiu a necessidade de outra variável. Nesse contexto, os editores da GUI da CLI e do ambiente de área de trabalho são mais ou menos os mesmos, portanto, você pode definir o VISUAL como um deles; no entanto, EDITOR é destinado a um fluxo de trabalho fundamentalmente diferente. Claro, tudo isso é histórico. Ninguém usa esses dias.
Zenexer

32

A resposta aceita é provavelmente um tratamento curto e bom, mas será uma tentativa de aprofundar quando a distinção entre VISUAL e EDITOR ainda for importante (com base na resposta de Adam Katz ).

A especificação POSIX ainda distingue entre editores de modo visual e editores de linha. Isso realmente importava nos dias em que o posicionamento do cursor sobre as conexões seriais era difícil (especialmente devido à velocidade da conexão serial). O artigo da Wikipedia para vi fornece algumas informações úteis sobre a distinção entre vi (um editor de modo visual) e ex (um editor de linha). Se você aprofundar o suficiente na pesquisa, encontrará a seção "RATIONALE" da especificação "ex" , que fornece um motivo para a distinção ainda estar na especificação:

Reconhece-se que partes do vi seriam difíceis, se não impossíveis, de serem implementadas satisfatoriamente em um terminal em modo de bloco ou em um terminal sem nenhuma forma de endereçamento do cursor, portanto, não é um requisito obrigatório que esses recursos funcionem em todos os terminais . É intenção, no entanto, que uma implementação vi forneça o conjunto completo de recursos em todos os terminais capazes de suportá-los.

Eu não precisava disso desde desistir do meu modem 300 baud, mas posso imaginar que as pessoas que usam linhas seriais lentas para conectar a sistemas embarcados (e / ou através de conexões realmente arriscadas) pode ainda apreciar a possibilidade de ter um modo de linha preferido editor distinto de um editor "visual" como o vi. Os códigos de terminal no estilo VT100 em uma conexão estreita, com perdas e com atraso podem estar "inchados" em aplicativos limitados.

Para o resto de nós, parece que a resposta "correta" parece "definir os dois como seu editor preferido". Pode ser correto cooptar essa distinção entre editor local / gráfico (por exemplo, Sublime ou gvim) e um editor de janela de terminal (por exemplo, vi ou emacs), mas provavelmente há uma série de razões legadas pelas quais isso provavelmente não funcionará como esperado .


2

Algumas ferramentas aceitam apenas EDITOR, por exemplo, o shell interno fc :

-e ENAME  select which editor to use.  Default is FCEDIT, then EDITOR, then vi

1

Concluí que $VISUALé gráfico e $EDITORé linha de comando. Se indefinido, qualquer coisa que procurar $VISUAL deve tentar a $EDITORseguir.

( Citação necessária: eu adoraria obter a documentação adequada, talvez uma página de manual ou uma especificação POSIX?)

No momento, eu tenho coisas assim no meu ~/.bashrce ~/.zshrc:

EDITOR="$(command -v vim)"

# we have gvim, not in an SSH term, and the X11 display number is under 10
if command -v gvim >/dev/null 2>&1 \
&& [ "$SSH_TTY$DISPLAY" = "${DISPLAY#*:[1-9][0-9]}" ]; then
  export VISUAL="$(command -v gvim) -f"
  SUDO_EDITOR="$VISUAL"
else
  SUDO_EDITOR="$EDITOR"
fi

gvimsem -fnão funcionará com programas que esperam atuar em suas edições. Isso definitivamente inclui sudoeditor( sudo -e).

Isso pode quebrar se você tiver um espaço em branco no caminho para o vim. Se isso for um problema, instale-o corretamente ou considere links simbólicos como/usr/local/bin/gvim


A utilização $VISUALdepende se você possui um terminal capaz de posicionar o cursor, e não se possui um sistema de janelas disponível.
Radon Rosborough 13/0318

Ah, ótimo! Você pode fornecer um link de referência definitivo para isso? Acho que meu código ainda está seguro, pois também estou procurando $DISPLAY, mas é bom saber.
23418 Adam

Não importa, parece que essas referências existem na resposta de robla , que até menciona a minha resposta.
14138 Adam

0

Como não parece haver nenhum ambiente em que vi ou similar falhe, decidi definir VISUAL para algo que precisa de um X DISPLAY e EDITOR para ex.

Principalmente, isso parece me causar problemas quando algum programa não usa o VISUAL.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.