Geralmente, defino as variáveis de ambiente VISUAL
e EDITOR
da mesma maneira, mas qual é a diferença? Por que eu os definiria de maneira diferente? Ao desenvolver aplicativos, por que devo optar por analisar VISUAL
antes EDITOR
ou vice-versa?
Geralmente, defino as variáveis de ambiente VISUAL
e EDITOR
da mesma maneira, mas qual é a diferença? Por que eu os definiria de maneira diferente? Ao desenvolver aplicativos, por que devo optar por analisar VISUAL
antes EDITOR
ou vice-versa?
Respostas:
O EDITOR
editor deve poder trabalhar sem o uso da funcionalidade "avançada" do terminal (como antigo ed
ou ex
modo de vi
). Foi utilizado em terminais de teletipo.
Um VISUAL
editor pode ser um editor de tela cheia como vi
ou emacs
.
Por exemplo, se você chamar um editor por meio do bash (usando C-x C-e
), o bash tentará o primeiro VISUAL
editor e, em seguida, se VISUAL
falhar (porque o terminal não suporta um editor em tela cheia), ele tenta EDITOR
.
Atualmente, você pode deixar a EDITOR
configuração ou configurá-la como vi -e
.
ed
e similares não são muito populares, então acredito que não há problema em ignorar VISUAL
e usar EDITOR
.
C-x C-e
no bash. Muito conveniente.
EDITOR
não é suficiente, por exemplo, git
no Ubuntu 12.04. Sem VISUAL
ser definido, git
ignora EDITOR
e apenas usa nano
(o compilado por padrão, eu acho).
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.
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 .
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
Concluí que $VISUAL
é gráfico e $EDITOR
é linha de comando. Se indefinido, qualquer coisa que procurar $VISUAL
deve tentar a $EDITOR
seguir.
( 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 ~/.bashrc
e ~/.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
gvim
sem -f
nã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
$VISUAL
depende se você possui um terminal capaz de posicionar o cursor, e não se possui um sistema de janelas disponível.
$DISPLAY
, mas é bom saber.
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.
$VISUAL
como 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 definirVISUAL
(eEDITOR
) o caminho completo para um executável (que pode ser um script de wrapper, se você quiser, por exemplo, opções).