VISUAL vs. EDITOR - jaka jest różnica?


182

Zasadniczo ustawiam zmienne środowiskowe VISUALi EDITORśrodowiskowe na to samo, ale jaka jest różnica? Dlaczego miałbym je ustawiać inaczej? Dlaczego podczas tworzenia aplikacji powinienem patrzeć VISUALprzedtem EDITORlub na odwrót?

Odpowiedzi:


145

EDITORRedaktor powinien być w stanie pracować bez użycia „Zaawansowane” terminala funkcjonalności (jak stary edlub extrybu vi). Użyto go na terminalach teletype.

VISUALEdytor może być pełny ekran jako redaktor vilub emacs.

Np. Jeśli wywołasz edytor przez bash (za pomocą C-x C-e), bash spróbuje najpierw VISUALedytora, a następnie, jeśli się VISUALnie powiedzie (ponieważ terminal nie obsługuje edytora pełnoekranowego), spróbuje EDITOR.

W dzisiejszych czasach możesz pozostawić EDITORnieuzbrojony lub ustawić go na vi -e.


9
Większość aplikacji traktuje $VISUALjako fragment powłoki, do którego dołączają nazwę pliku (cytowaną w powłoce), ale niektóre traktują ją jako nazwę pliku wykonywalnego, w którym mogą wyszukiwać lub nie $PATH. Dlatego najlepiej ustawić VISUAL(i EDITOR) pełną ścieżkę do pliku wykonywalnego (który może być skryptem opakowania, jeśli chcesz np. Opcji).
Gilles

4
W dzisiejszych czasach edi tym podobne nie są zbyt popularne, więc uważam, że po prostu zignoruj VISUALi użyj EDITOR.
Pavel Šimerda

13
Dzięki za poradę C-x C-ew bash. Bardzo przydatny.
mndrix,

5
@ PavelŠimerda, samo ustawienie EDITORto za mało, np. Dla gitUbuntu 12.04. Bez VISUALustawienia gitignoruje EDITORi po prostu używa nano(domyślnie jest to kompilacja).
maxschlepzig

5
@ PavelŠimerda To nie ma sensu, ale to konwencja. EDITOR był kiedyś edytorem opartym na instrukcjach ed. Kiedy powstały edytory z GUI - a przez GUI mam na myśli GUI CLI (vim, emacs itp. - Think ncurses), a nie GUI środowiska graficznego - proces edycji zmienił się diametralnie, więc pojawiła się potrzeba innej zmiennej. W tym kontekście edytory GUI CLI i środowiska graficznego są mniej więcej takie same, więc możesz ustawić VISUAL na jeden z nich; jednak EDYTOR przeznaczony jest do zasadniczo innego przepływu pracy. Oczywiście to wszystko jest historyczne. Obecnie nikt nie używa ed.
Zenexer

32

Przyjęta odpowiedź jest prawdopodobnie dobrym, krótkim traktowaniem, ale będzie to próba głębszego zbadania, kiedy różnica między VISUAL a EDITOREM może nadal mieć znaczenie (w oparciu o odpowiedź Adama Katza ).

Specyfikacja POSIX wciąż rozróżnia edytory trybu wizualnego i edytory liniowe. To naprawdę miało znaczenie w czasach, gdy pozycjonowanie kursora nad połączeniami szeregowymi było trudne (szczególnie ze względu na szybkość połączenia szeregowego). Artykuł w Wikipedii dotyczący vi zawiera przydatne informacje na temat rozróżnienia między vi (edytor trybu wizualnego) i ex (edytor linii). Jeśli zagłębisz się wystarczająco głęboko w badania, znajdziesz sekcję „RATIONALE” specyfikacji „ex” , która daje powód, dla którego wciąż wyróżnia się to w specyfikacji:

Uznaje się, że części vi byłyby trudne, jeśli nie niemożliwe, do zadowalającej implementacji na terminalu w trybie blokowym lub terminalu bez jakiejkolwiek formy adresowania kursora, dlatego nie jest obowiązkowym wymogiem, aby takie funkcje działały na wszystkich terminalach . Jednak intencją jest, aby implementacja vi zapewniała pełny zestaw możliwości na wszystkich terminalach zdolnych do ich obsługi.

Nie potrzebowałem tego, odkąd zrezygnowałem z modemu o szybkości 300 bodów, ale mogę sobie wyobrazić, że ludzie, którzy używają wolnych linii szeregowych do łączenia się z systemami wbudowanymi (i / lub za pośrednictwem bardzo dicey połączeń) nadal mogą docenić możliwość wyboru preferowanego trybu linii edytor różni się od edytora „wizualnego”, takiego jak vi. Kody terminali w stylu VT100 w przypadku stratnego, opóźnionego, wąskiego połączenia mogą być „rozdęte” w ograniczonych aplikacjach.

Dla reszty z nas wydaje się, że „poprawną” odpowiedzią wydaje się być „ustaw je jako preferowany edytor”. Dobrym rozwiązaniem może być wybranie tego rozróżnienia dla edytora lokalnego / graficznego (np. Sublime lub gvim) w porównaniu z edytorem okien terminalowych (np. Vi lub emacs), ale prawdopodobnie istnieje wiele starszych powodów, dla których prawdopodobnie nie zadziała tak, jak się spodziewano .


2

Niektóre narzędzia akceptują tylko EDYTOR, na przykład wbudowana powłoka fc :

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

1

Doszedłem do wniosku, że $VISUALto grafika i $EDITORlinia poleceń. Jeśli nie jest zdefiniowane, cokolwiek szukającego $VISUAL powinno następnie spróbować $EDITORdalej.

( Potrzebne cytowanie: Chciałbym uzyskać odpowiednią dokumentację, może stronę podręcznika lub specyfikację POSIX?)

W tej chwili mam takie rzeczy w mojej ~/.bashrci ~/.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

gvimbez -fnie będzie działać z programami, które oczekują, że wprowadzą zmiany. To zdecydowanie obejmuje sudoeditor( sudo -e).

Może się to zepsuć, jeśli masz spacje na ścieżce do vima. Jeśli to jest problem, albo zainstaluj go poprawnie, albo rozważ takie dowiązania symboliczne/usr/local/bin/gvim


To, czy użyć, $VISUALzależy od tego, czy masz terminal zdolny do pozycjonowania kursora, a nie od tego, czy masz dostępny system okien.
Radon Rosborough

Ach, świetnie! Czy możesz podać definitywny link referencyjny? Myślę, że mój kod jest nadal bezpieczny, ponieważ sprawdzam również $DISPLAY, ale dobrze wiedzieć.
Adam Katz

Nieważne, wydaje się, że takie odniesienia istnieją w odpowiedzi Robli , która nawet wspomina moją odpowiedź.
Adam Katz

0

Ponieważ wydaje się, że nie ma żadnych środowisk, w których zawiodłoby vi lub podobne, postanowiłem ustawić VISUAL na coś, co wymaga X WYŚWIETLACZA, a EDYTORA np.

W większości przypadków wydaje mi się to powodować problemy, gdy jakiś program nie używa VISUAL.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.