Naprawianie CTRL- * w vimie pod ekranem GNU

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).

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

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.

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.