Generalmente configuro las variables de entorno VISUALy EDITORlas mismas para lo mismo, pero ¿cuál es la diferencia? ¿Por qué los pondría de manera diferente? Al desarrollar aplicaciones, ¿por qué debería elegir mirar VISUALantes EDITORo viceversa?
Respuestas:
El EDITOReditor debe poder trabajar sin el uso de la funcionalidad de terminal "avanzada" (como antigua edo exmodo de vi). Fue utilizado en terminales de teletipo.
Un VISUALeditor podría ser un editor de pantalla completa como vio emacs.
Por ejemplo, si invoca un editor a través de bash (usando C-x C-e), bash probará el primer VISUALeditor y luego, si VISUALfalla (porque el terminal no admite un editor de pantalla completa), lo intenta EDITOR.
Hoy en día, puede dejarlo sin EDITORconfigurar o configurarlo vi -e.
edy similares, no son muy populares, así que creo que está bien ignorarlos VISUALy usarlos EDITOR.
C-x C-ebash. Muy útil.
EDITORno es suficiente, por ejemplo, giten Ubuntu 12.04. Sin VISUALser configurado gitignora EDITORy solo usa nano(el compilado por defecto, supongo).
ed. Cuando surgieron editores con GUI, y por GUI, me refiero a la GUI de CLI (vim, emacs, etc.), no a la GUI del entorno de escritorio, el proceso de edición cambió drásticamente, por lo que surgió la necesidad de otra variable. En este contexto, los editores de la GUI de la CLI y del entorno de escritorio son más o menos iguales, por lo que puede configurar VISUAL en cualquiera de los dos; sin embargo, EDITOR está destinado a un flujo de trabajo fundamentalmente diferente. Por supuesto, todo esto es histórico. Nadie usa ed en estos días.
La respuesta aceptada es probablemente un buen y breve tratamiento, pero este será un intento de profundizar cuando la distinción entre VISUAL y EDITOR podría seguir siendo importante (basándose en la respuesta de Adam Katz ).
La especificación POSIX todavía distingue entre editores de modo visual y editores de línea. Esto realmente importaba en los días en que el posicionamiento del cursor sobre las conexiones en serie era difícil (especialmente debido a la velocidad de la conexión en serie). El artículo de Wikipedia para vi ofrece algunos antecedentes útiles sobre la distinción entre vi (un editor de modo visual) y ex (un editor de línea). Si profundiza lo suficiente en la investigación, encontrará la sección "JUSTIFICACIÓN" de la especificación "ex" , que da una razón para la distinción que aún se encuentra en la especificación:
Se reconoce que partes de vi serían difíciles, si no imposibles, de implementar satisfactoriamente en un terminal en modo de bloque, o un terminal sin ninguna forma de direccionamiento del cursor, por lo tanto, no es un requisito obligatorio que tales características funcionen en todos los terminales . Sin embargo, la intención es que una implementación vi proporcione el conjunto completo de capacidades en todos los terminales capaces de soportarlos.
No he necesitado esto ya que renunciar a mi módem de 300 baudios, pero puedo imaginar que las personas que usan líneas serie lentos para conectarse a sistemas embebidos (y / o a través de conexiones muy inciertas) podría todavía aprecian la posibilidad de tener un modo de línea preferida editor distinto de un editor "visual" como vi. Los códigos de terminal de estilo VT100 a través de una conexión estrecha, lenta y con pérdida pueden estar "abarrotados" en aplicaciones limitadas.
Para el resto de nosotros, parece que la respuesta "correcta" parece ser "configurar a ambos como su editor preferido". Podría estar bien cooptar esta distinción para el editor local / gráfico (por ejemplo, Sublime o gvim) frente a un editor de ventana de terminal (por ejemplo, vi o emacs), pero es probable que haya una gran cantidad de razones heredadas por las que eso probablemente no funcionará como se esperaba .
Algunas herramientas solo aceptan EDITOR, por ejemplo el shell incorporado fc :
-e ENAME select which editor to use. Default is FCEDIT, then EDITOR, then vi
He concluido que $VISUALes gráfico y $EDITORes la línea de comando. Si no está definido, cualquier cosa que busque $VISUAL debe intentarlo a $EDITORcontinuación.
( Cita necesaria: me encantaría obtener la documentación adecuada, ¿tal vez una página de manual o una especificación POSIX?)
Por el momento, tengo cosas como esta en mi ~/.bashrcy ~/.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
gvimSin -fno funcionará con programas que esperan actuar en sus ediciones. Esto definitivamente incluye sudoeditor( sudo -e).
Esto puede romperse si tiene espacios en blanco en el camino a vim. Si eso es un problema, instálalo correctamente o considera enlaces simbólicos como/usr/local/bin/gvim
$VISUALdepende de si tiene un terminal capaz de posicionar el cursor, no de si tiene un sistema de ventanas disponible.
$DISPLAY, pero es bueno saberlo.
Como no parece haber ningún entorno en el que vi o similar falle, he decidido configurar VISUAL en algo que necesita una PANTALLA X, y EDITOR en ex.
Principalmente, eso parece causarme problemas cuando algún programa no usa VISUAL.
$VISUALcomo un fragmento de shell al que agregan el nombre del archivo (entre comillas), pero algunas lo tratan como el nombre de un ejecutable en el que pueden buscar o no$PATH. Por lo tanto, es mejor establecerVISUAL(yEDITOR) en la ruta completa a un ejecutable (que podría ser un script de envoltura si desea, por ejemplo, opciones).