Naprawianie CTRL- * w vimie pod ekranem GNU

10

Kiedy uruchamiam vima pod ekranem GNU, stwierdzam, że kombinacje klawiszy CTRLze strzałką i klawiszami Pg * nie działają zgodnie z oczekiwaniami.

Korzystam z vim-gnomepakietu Ubuntu 10.10 .

Na innej maszynie, również z systemem Ubuntu, działało to bez problemów; niestety nie mam teraz dostępnej takiej konfiguracji.

Tutaj jest powiązane pytanie: jak naprawić Ctrl + strzałki w Vimie?

Jednak sugerowanym rozwiązaniem jest ponowne mapowanie skrótów klawiszowych vima do pracy z emulatorem terminala, w tym przypadku PuTTY. Nie przypominam sobie robienia czegoś podobnego i podejrzewam, że istnieje opcja konfiguracji ekranu, która rozwiąże ten problem.

Istnieje również wątek na liście mailingowej GNU, który sugeruje, że uruchomienie vim za pośrednictwem $ TERM=xterm vimjest odpowiednią poprawką lub obejściem. To działa, ale jestem trochę zaniepokojony, że mogą wystąpić skutki uboczne. Nie brzmi też wystarczająco znajomo, aby być rozwiązaniem, które ustawiłem na innym komputerze (jeśli rozwiązanie było konieczne).

ubuntu vim gnu-screen intuicyjny
źródło
+1 - miałem ten sam problem i - jak sugerowałeś - dodanie term xtermdo mojego ~/.screenrcpliku naprawiło to dla mnie. Dzięki jeszcze raz!
Justin Ethier

Odpowiedzi:

4

Jak intuicyjnie stwierdził w swojej aktualizacji, dodanie term xtermdo ~/.screenrcpliku wydaje się rozwiązać ten problem.

Justin Ethier
źródło
No cóż… tak, ale zastanawiam się, dlaczego screennie propaguje $TERMzmiennej środowiskowej zamiast jej zastępowania "screen". Przypuszczalnie istnieją pewne okoliczności, w których warto to mieć $TERM == screen.
intuicyjnie
3
@intuited: Powodem ustawiania Screen TERM=screenjest to, że aplikacje działające w nim komunikują się wewnątrz terminala Screen: sekwencje sterujące, które wysyłają i odbierają, są sekwencjami Screen, a nie sekwencjami wyświetlanymi na ekranie. Ponieważ możesz odłączyć sesję Screen i ponownie podłączyć ją do innego rodzaju terminala, ta warstwa pośrednictwa jest konieczna.
Gilles „SO- przestań być zły”
@Gilles: Dzięki, podejrzewałem coś takiego. Jakie problemy mogą wynikać z przywrócenia ustawień xterm?
intuicyjnie
1
Niewiele, ponieważ xterm i screen są w większości kompatybilne. Ale każda z nich ma kilka funkcji, których nie ma druga, a jeśli okłamujesz aplikacje, mogą one skorzystać z funkcji, która w rzeczywistości nie działa. Porównaj dane wyjściowe infocmp screeni infocmp xtermoraz sekwencje specjalne ekranu z sekwencjami wyjściowymi xterm . Nie mam podziału na ofertę; większości aplikacji nie będzie to przeszkadzało, ale niektóre mogą zachowywać się denerwująco.
Gilles „SO- przestań być zły”
2

Istnieje kilka innych sposobów ustawienia terminala, który działa podczas uruchamiania procesów:

  • W uruchomionej instancji ekranu naciśnięcie ^A- :i wydanie polecenia term xtermspowoduje, że nowo otwarte ekrany w tej instancji zaczną się ze $TERMzmienną środowiskową ustawioną na xterm; to z kolei rozprzestrzeni się na wywołane viminstancje. Te instancje vim będą wyświetlać prawidłowe zachowanie w odniesieniu do kombinacji CTRL; Nie odkryłem jeszcze żadnych skutków ubocznych tej strategii. To polecenie nie wpływa na istniejące ekrany. Tego polecenia można oczywiście użyć w ~/.screenrcpliku, więc możliwe jest, że ta metoda została zastosowana na innym komputerze.

  • W działającej instancji vim polecenie set term=xtermsprawi, że kombinacje CTRL będą działać w tej instancji vim. Ma to efekt uboczny odłączenia schowka X (tj. @*I @+) z powodów, których jeszcze nie rozumiem. Co ciekawe, efekt uboczny schowka występuje również wtedy, gdy polecenie :set term=screenjest wykonywane w uruchomionej instancji vim $TERM=xterm.

phunehehe
źródło
Ta odpowiedź pochodzi z aktualizacji PO. Wszystko, co zrobiłem, to trochę sformatować i przeredagować.
phunehehe
2

Podstawowym problemem jest to, że mapowanie wykonane screenmiędzy rzeczywistym terminalem (identyfikowanym przez TERMzmienną środowiskową na zewnątrz screen) a emulacją wewnątrz screenjest niepełne.

Jeśli zdarzy ci się go przetestować (używając vttest lub tack ), możesz zauważyć braki

  • zabarwienie
  • klucze specjalne

Próbując rozwiązać te problemy poprzez ustawienie termw .screenrcma tę wadę, że działa tylko na dany rzeczywisty-terminal, a nie jest przenośny do innych implementacjach terminali. W dokumentacji notatki

Nie zaleca się używania terminu „komenda” do celów innych niż domyślne.

Istnieje inne rozwiązanie (z inną wadą), wykorzystujące tę funkcję z screen dokumentacji :

Kiedy screen próbuje sam wymyślić nazwę terminala, najpierw szuka wpisu o nazwie screen. termin , gdzie termin jest zawartością $TERMzmiennej. Jeśli nie ma takiego wpisu, screen próbuje screen(lub screen-w, jeśli terminal jest szeroki (132 cols lub więcej)). Jeśli nawet tego wpisu nie można znaleźć, vt100jest używany jako zamiennik.

ncurses zapewnia kilka przydatnych alternatywnych opisów terminali dla tego przypadku, np. screen.xterm-new , aby naprawić problemy z mapowaniem ekranu. W praktyce używam TERM=xterm-new, a podczas uruchamiania ekranu uzyskuję użyteczne mapowanie klawiszy funkcyjnych.

Nawiązując do termustawień ekranu , podczas testowania możesz zauważyć, że nadal występują problemy z mapowaniem, które są rozwiązane w tych alternatywach. Gdyby możliwe było uzyskanie dokładnego opisu terminala przy użyciu term, te alternatywy byłyby prostymi aliasami do screen. Oni nie są.

ncurses nie zapewnia screen.xterm(sic), ponieważ:

  • TERM=xtermjest powszechnie wykorzystywany do emulatorów terminali, które różnią się od xterm; dodanie tego mapowania tylko pogorszyłoby tę sytuację (patrz na przykład: dlaczego nie użyć TERM ustawionego na „xterm”? w FAQ ncurses)
  • alternatywna nazwa screen.xtermjest mniej prawdopodobna do zainstalowania na zdalnych systemach (patrz komentarz do zmiany od czerwca 2015 r. w bazie danych terminali).

Ogólnie rzecz biorąc, używanie alternatywnych nazw jest ulepszeniem w stosunku do używania termw twoim .screenrc: rozwiązuje więcej problemów niż tworzy. Odwrotna jest prawda w przypadku termustawienia.

Thomas Dickey
źródło