Виправлення CTRL- * in vim під екраном GNU

Запускаючи vim під екраном GNU, я виявляю, що комбінації клавіш CTRLзі стрілкою та клавішею Pg * не працюють як слід.

Я використовую vim-gnomeпакет Ubuntu 10.10 .

На іншій машині, також під керуванням Ubuntu, це спрацювало без проблем; на жаль, зараз у мене немає такої конфігурації.

Тут пов'язане запитання: як виправити Ctrl + стрілки у Vim?

Однак, пропоноване рішення полягає в тому, щоб перевстановити зв'язки клавіш vim для роботи з термінальним емулятором, у цьому випадку PuTTY. Я не пам'ятаю, щоб робити щось подібне, і підозрюю, що існує параметр налаштування екрана, який вирішить цю проблему.

У списку розсилки gnu-екрану також є нитка, яка дозволяє припустити, що запуск vim via $ TERM=xterm vimє відповідним виправленням або вирішенням. Це працює, але я трохи стурбований тим, що можуть бути побічні ефекти. Це також не звучить достатньо звично, щоб бути рішенням, яке я створив на іншій машині (якщо рішення було необхідним).

Як інтуїтивно заявлено у своєму оновленні, додавання term xtermдо ~/.screenrcфайлу, здається, вирішує цю проблему.

Є кілька інших способів встановити термінал, який працює в запущених процесах:

• У запущеному екземплярі екрану натискання ^A- :і видача команди term xtermпризведе до того, що нововідкриті екрани під цим екземпляром починатимуться із $TERMзмінної їх середовища xterm; це, в свою чергу, пошириться на викликані vimекземпляри. Ці випадки vim відображатимуть належну поведінку стосовно комбінацій CTRL; Я ще не виявив жодних побічних ефектів цієї стратегії. Ця команда не впливає на існуючі екрани. Ця команда, звичайно, може бути використана у ~/.screenrcфайлі, тому можливо, що цей метод був використаний на іншій машині.

• У запущеному екземплярі vim команда set term=xtermзмусить CTRL-комбо працювати в цьому екземплярі vim. Це має побічний ефект від відключення буфера обміну X (тобто @*і @+) з причин, які я ще не розумію. Цікаво, що побічний ефект буфера обміну буває і тоді, коли команда :set term=screenвиконується в екземплярі vim, розпочатому з $TERM=xterm.

Основна проблема полягає в тому, що відображення, зроблене screenміж фактичним терміналом (ідентифікованим TERMзмінною середовища зовні screen) та емуляцією всередині, screenє неповним.

Якщо у вас трапиться тестування (за допомогою vttest або tack ), ви можете помітити недоліки для

• кольори
• спеціальні ключі

Спроба вирішити ці проблеми шляхом установки termв .screenrcмає недолік , що полягає в тому , що він працює тільки для даного фактичного терміналу, і не підходить для інших терміналів реалізації. У документації примітки

Використання команди термін перешкоджає невиконанню цілей.

Є ще одне рішення (з іншим недоліком), використовуючи цю функцію з screen документації :

Коли екран намагається з'ясувати назву термінала для себе, він спочатку шукає запис з ім'ям екрана. термін , де термін - це зміст вашої $TERMзмінної. Якщо такої записи немає, спробуйте зробити екран screen(або screen-w, якщо термінал широкий (132 cols або більше)). Якщо навіть цей запис не може бути знайдена, vt100використовуються в якості заміни.

ncurses надає кілька корисних альтернативних описів терміналів для цього випадку, наприклад, screen.xterm-new , щоб усунути проблеми з відображенням екрана. На практиці я використовую TERM=xterm-newі під час запуску екрана отримую корисне відображення функціональних клавіш.

Повертаючись до termналаштувань екрана , під час тестування ви можете помітити, що все ще існують проблеми із картографуванням, які вирішено в цих альтернативах. Якби вдалося отримати точний опис терміналу за допомогою termцих альтернатив, було б простим псевдонімом screen. Вони не.

ncurses не надає screen.xterm(sic), оскільки:

• TERM=xtermшироко застосовується для термінальних емуляторів, які відрізняються від xterm; додавання цього відображення тільки погіршить цю ситуацію (див. наприклад, чому б просто не використовувати термін, встановлений на "xterm"? у ncurses FAQ)
• альтернативна назва screen.xtermрідше буде встановлена ​​у віддалених системах (див. коментар до змін від червня 2015 року в базі даних терміналів).

Однак загалом використання альтернативних імен є вдосконаленням у порівнянні з використанням termваших .screenrc: це вирішує більше проблем, ніж створює. Зворотний варіант відповідає дійсності term.