Je règle généralement les deux variables d'environnement VISUALet EDITORà la même chose, mais quelle est la différence? Pourquoi devrais-je les configurer différemment? Lors du développement d'applications, pourquoi devrais-je choisir de regarder VISUALavant EDITORou vice versa?
Réponses:
L' EDITORéditeur devrait pouvoir fonctionner sans utiliser les fonctionnalités "avancées" du terminal (comme l'ancien edou le exmode de vi). Il était utilisé sur les terminaux de télétype.
Un VISUALéditeur peut être un éditeur plein écran en tant que viou emacs.
Par exemple, si vous appelez un éditeur via bash (using C-x C-e), bash essaiera d'abord l' VISUALéditeur, puis VISUALéchouera (car le terminal ne prend pas en charge un éditeur plein écran), il essaiera EDITOR.
De nos jours, vous pouvez laisser EDITORnon défini ou le définir sur vi -e.
edet similaires ne sont pas très populaires, donc je crois qu'il est correct d'ignorer VISUALet d'utiliser EDITOR.
C-x C-ebash. Très utile.
EDITORne suffit pas, par exemple pour gitUbuntu 12.04. Sans VISUALêtre défini gitignore EDITORet utilise simplement nano(le compilé par défaut, je suppose).
ed. Lorsque les éditeurs avec des interfaces graphiques ont vu le jour - et par interface graphique, j'entends l'interface graphique de la CLI (vim, emacs, etc. - think ncurses), et non l'interface graphique de l'environnement de bureau - le processus de modification a été radicalement modifié, d'où la nécessité d'une autre variable. Dans ce contexte, les éditeurs d’interface graphique de l’interface graphique et de l’environnement de bureau sont plus ou moins identiques, vous pouvez donc définir VISUAL sur: Cependant, EDITOR est destiné à un flux de travail fondamentalement différent. Bien sûr, tout cela est historique. Personne n'utilise ed ces jours-ci.
La réponse acceptée est probablement un traitement court et de bonne qualité, mais ce sera une tentative d'approfondissement lorsque la distinction entre VISUAL et EDITOR pourrait toujours être importante (en s'appuyant sur la réponse d'Adam Katz ).
La spécification POSIX fait encore la distinction entre les éditeurs en mode visuel et les éditeurs en ligne. Cela importait vraiment à l'époque où le positionnement du curseur sur les connexions série était difficile (notamment à cause de la vitesse de la connexion série). L' article de Wikipedia sur vi fournit des informations utiles sur la distinction entre vi (éditeur de mode visuel) et ex (éditeur de ligne). Si vous approfondissez suffisamment la recherche, vous trouverez la section "JUSTIFICATION" de la spécification "ex" , qui donne une raison pour que la distinction soit toujours dans la spécification:
Il est reconnu que des parties de vi seraient difficiles, voire impossibles, à mettre en œuvre de manière satisfaisante sur un terminal en mode bloc ou un terminal sans aucune forme d'adressage de curseur. Il n'est donc pas obligatoire que ces fonctionnalités fonctionnent sur tous les terminaux. . Toutefois, une implémentation vi devrait fournir l’ensemble complet des capacités de tous les terminaux capables de les prendre en charge.
Je n’en ai plus besoin depuis que j’ai abandonné mon modem 300 bauds, mais j’imagine que les personnes utilisant des lignes série lentes pour se connecter à des systèmes intégrés (et / ou sur des connexions vraiment risquées) pourraient tout de même souhaiter pouvoir bénéficier d’un mode de ligne préféré. éditeur distinct d'un éditeur "visuel" comme vi. Les codes de terminal de style VT100 sur une connexion étroite avec perte, lente et lente peuvent être "bouffis" dans des applications limitées.
Pour le reste d'entre nous, il semble que la réponse "correcte" semble être "configurez-les tous les deux pour qu'ils soient votre éditeur préféré". Il serait peut-être acceptable d’utiliser cette distinction pour un éditeur local / graphique (par exemple, Sublime ou gvim) par rapport à un éditeur de fenêtre terminal (par exemple, vi ou emacs), mais il existe probablement une multitude de raisons pour lesquelles cela ne fonctionnera probablement pas comme prévu. .
Certains outils acceptent uniquement EDITOR, par exemple le shell intégré fc :
-e ENAME select which editor to use. Default is FCEDIT, then EDITOR, then vi
J'ai conclu qu'il $VISUALs'agit d'un graphique et d'une $EDITORligne de commande. Si non défini, tout ce qui cherche $VISUAL devrait alors essayer $EDITORensuite.
( Citation nécessaire: j'aimerais obtenir la documentation appropriée, peut-être une page de manuel ou une spécification POSIX?)
Pour le moment, j'ai des trucs comme ça dans mon ~/.bashrcet ~/.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"
figvimsans -fne fonctionnera pas avec les programmes qui s'attendent à agir sur vos modifications. Cela inclut certainement sudoeditor( sudo -e).
Cela peut casser si vous avez des espaces dans le chemin de vim. Si cela pose un problème, installez-le correctement ou utilisez des liens symboliques comme/usr/local/bin/gvim
$VISUALVous devez utiliser ou non un terminal capable de positionner le curseur et non un système de fenêtre.
$DISPLAY, mais c'est bon à savoir.
Puisqu'il ne semble exister aucun environnement où vi ou similaire échouerait, j'ai commencé à définir VISUAL sur quelque chose nécessitant un X DISPLAY et EDITOR un exemple.
Surtout, cela semble juste me causer des problèmes lorsque certains programmes n'utilisent pas VISUAL.
$VISUALcomme un fragment de shell auquel elles ajoutent le nom de fichier (cité), mais certaines le traitent comme le nom d'un fichier exécutable dans lequel elles peuvent ou non effectuer une recherche$PATH. Il est donc préférable de définirVISUAL(etEDITOR) le chemin complet d'un exécutable (qui pourrait être un script wrapper si vous voulez, par exemple, des options).