Вопросы Теги

Проблема Tmux Terminfo с привязками клавиш Zsh

Xubuntu.

XFCE смотрит лучше и является меньшим количеством спартанца, чем LXDE, я сохранил любимую Ubuntu, панель XFCE является большой, работы Compiz-Fusion, перетаскивание не является никакой проблемой между Thunar (файловый менеджер XFCE) и Наутилусом (Gnome один) и рабочий стол. Чистая установка Xubuntu была бы лучше, но нет никаких основных проблем, я счастлив теперь.

1
07.12.2012, 05:38
3 ответа

Первая проблема состоит в том что Ваша terminfo запись для screen не определяет a kDC3 возможность; это, вероятно, типично. Можно или добавить эту возможность к собственному screen запись, или можно “трудно кодировать” последовательности в Вашем bindkey команды.

Добавление возможностей может помочь другим программам знать о ключах, но оно децентрализует Вашу конфигурацию (было бы легко забыть об этой настройке при ручном тиражировании конфигурации в новую машину или учетную запись пользователя). Можно извлечь соответствующие записи с infocmp и создайте новую запись с tic:

{ infocmp -xT screen ; infocmp -x1T xterm | grep -E '^\tkDC[3-8]?=' ; } >/tmp/s
tic -x /tmp/s

Если Вы выполняете тик как пользователь, который имеет доступ для записи к Вашему terminfo каталогу (например. /usr/share/terminfo), затем новая запись будет помещена туда (вероятно, перезаписывающий исходную запись); иначе это будет помещено под ~/.terminfo (или TERMINFO, если Вам установили ту переменную среды).

Для полноты можно хотеть использовать (UP|DN|RIT|LFT|PRV|NXT|HOM|END|IC|DC) вместо DC в grep шаблоне для получения измененных версий, Вниз, Право, Левое, PageUp, PageDown, Домой, Конец, Вставляют и Удаляют.

Если Вам не нравится децентрализация конфигурации, вызванная путем настройки terminfo записи, то можно “трудно кодировать” значение вместо этого. Для создания его немного лучше можно проверить на kDC3 во-первых:

bindkey -e ${$(tput kDC3 2>/dev/null):-'\e[3;3~'} kill-word

Ограничить это “трудное кодирование” просто screen- основанные значения ТЕРМИНА:

altdel=$(tput kDC3 2>/dev/null)
[[ -z $altdel && $TERM == screen(|-*) ]] && altdel='\e[3;3~'
[[ -n $altdel ]] && bindkey -e $altdel kill-word
unset altdel

Это будет работать, пока Ваш эмулятор терминала (стек) заканчивает тем, что генерировал последовательность xterm-стиля для измененного ключа.

Однажды, чтобы иметь привязку, необходимо будет все еще включить xterm-keys опция в tmux так, чтобы это генерировало последовательности xterm-стиля для ключей, передала в его области. Например, в Вашем ~/.tmux.conf:

set-option -wg xterm-keys on
4
27.01.2020, 23:17
  • 1
    Спасибо. Существует ли вероятная причина xterm-ключей, не включаемых по умолчанию и возможности, не являющейся установкой по умолчанию? –  aef 07.12.2012, 20:42
  • 2
    я думаю, что они связаны. screen запись terminfo документирует коды, которые экранная программа понимает и генерирует; я не думаю, что экран понимает, ни генерирует коды xterm-стиля (хотя это, действительно кажется, передает их через), таким образом, они не часть screen запись terminfo. xterm-keys опция представляет расширение основного screen возможности (что tmux рекламирует при помощи TERM=screen), таким образом, это не по умолчанию (возможно, это мог быть on-by-default когда (например). TERM=tmux, если tmux когда-нибудь решает разветвить свою собственную terminfo запись). –  Chris Johnsen 07.12.2012, 21:18

Из того, что я видел внутренностей tmux, это, кажется, не обращает много внимания на terminfo настройки и т.п.. Например, если Вы включаете xterm режим:

set-window-option -g xterm-keys on

фактические escape-последовательности, соответствующие различным ключам, являются hardcoded в программу и вероятно отличаются от какой infocmp xterm сказал бы Вам.

Вдобавок к этому tmux игнорирует все выше F20 потому что это только имеет определенный набор ключей, в которых это распознает hardcoded. Так что-то вроде этого 

set-option -g terminal-overrides "screen:kf34=\033[21;5~"

или 

tmux bind-key -t emacs-copy F34 page-up

движение не должно выполнять ничего, независимо от того, что выкладывают xterm или tput. По крайней мере это - способ, которым это, кажется, в настоящее время.

Я не уверен, производит ли та же проблема что-то как kDC3 но это кажется довольно возможным.

0
27.01.2020, 23:17

Это зависит:

  • ncurses поддерживает расширенные (определяемые пользователем) терминальные возможности.
  • kDC3 является расширенной терминальной возможностью.
  • Никто из tmux, zsh или emacs не знает ничего вообще о kDC3.
  • хотя tmux имеет kDC3 в таблице, он не вызывает use_extended_names для включения этой функции.
  • ncurses tput будет знать о kDC3, если он определен в описании текущего терминала.

Программа screen (которую имитирует tmux) также ничего не знает о kDC3. Она является termcap приложением, и (для себя) обращает внимание только на двухсимвольные имена. Однако у screen есть функция, которая напрямую решает этот вопрос: в руководстве (16.1 Выбор записи termcap для окна) рассказывается, как он выбирает настройку для TERM внутри экранной сессии:

Когда screen пытается выяснить имя терминала для себя, он сначала ищет запись с именем screen. term, где term - это содержимое вашей переменной $TERM. Если такой записи не существует, screen пытается выполнить screen (или screen-w, если терминал широкий (132 столбца или более)). Если и эта запись не найдена, в качестве замены используется vt100 .

Идея заключается в том, что если у вас есть терминал, который не поддерживает важную функцию (например, delete char или clear to EOS), вы можете создать новую запись termcap/terminfo для screen (с именем screen.dumbterm), в которой эта возможность отключена. Если эта запись установлена на ваших машинах, вы можете сделать rlogin и сохранить правильную запись termcap/terminfo. Имя терминала помещается в переменную $TERM всех новых окон. screen также устанавливает переменную $TERMCAP, отражающую возможности эмулируемого виртуального терминала. Кроме того, переменная $WINDOW устанавливается в номер окна каждого окна. База данных терминалов

ncurses использует эту особенность для предоставления наиболее распространенных вариантов screen с xterm и другими терминалами, которые похожи, но имеют разные функциональные клавиши, такие как konsole, vte (например, gnome-terminal), rxvt. За исключением rxvt, остальные по-прежнему устанавливают TERM на xterm.

В стандартной конфигурации у вас может не быть этих описаний терминалов (и screen будет продолжать беспечно устанавливать TERM=screen и провоцировать пользователей на сообщения об ошибках, подобные этому вопросу). Debian, например, в своём пакете ncurses-base terminfo предоставляет только минимальный набор описаний терминалов. Вам придётся установить ncurses-term для получения полной базы данных терминалов.

Описание терминала для screen, конечно, не описывает никаких расширенных функциональных клавиш. Оно, кстати, включает эти расширенные возможности:

AX, G0, E0=\E(B, S0=\E(%p1%c,

но ни одно из этих приложений (кроме tput) ничего с ними не делает.

tmux усложняет ситуацию тем, что не полностью соответствует поведению screen: он не проверяет наличие альтернативных имен, которые предоставляет ncurses. Не объясняя причин, на странице руководства сказано

Переменная окружения TERM должна быть установлена в "screen" для всех программ, работающих внутри tmux. Новые окна будут автоматически иметь "TERM=screen", добавленную в их окружение, но нужно быть осторожным, чтобы не сбросить это значение в файлах запуска оболочки.

Вероятная причина в том, что разработчик не хотел гарантировать поведение (для обновления экрана) возможностей терминала, не найденных в screen. Функциональные клавиши - это совсем другое дело. Вы можете изменить описание терминала, как было предложено, хотя это оказалось больше проблемой, чем решением:

Предложенный скрипт, кстати, похоже, не работает. Показывать исправленный скрипт было бы бессмысленно, учитывая всю подоплеку этой проблемы. Вместо того, чтобы по частям изменять базу данных терминала, я бы склонялся к тому, чтобы в инициализации оболочки был оператор case, который проверял бы наличие TERM, установленного на screen, и проверить, есть ли лучшая альтернатива в базе данных терминала. Правильное выполнение этой задачи усложняется отказом разработчиков устанавливать TERM в соответствии с возможностями терминала, но вы можете проделать большую часть пути, посмотрев на переменную окружения COLORTERM.

Для вашего развлечения:

1
27.01.2020, 23:17

Теги

Похожие вопросы