Получите экран «linux», чтобы распознать xterm mouse-click cols & gt; 95

Ничего, я нашел ответ здесь. Проблема была в AppArmor.

0
задан 6 November 2017 в 08:40

3 ответа

Унаследованный протокол мыши использует необработанные байты для каждой координаты (координата плюс 32). Таким образом, он поддерживает только координаты до 223 (223 + 32 = 255, самое большое значение, которое может содержать байты).

В некоторых ситуациях, например. когда происходит преобразование набора символов или когда какой-то компонент требует, чтобы данные, проходящие через, были действительными UTF-8, байты в диапазоне 128-255 также становятся проблематичными. Таким образом, клики работают надежно только до столбца и строки 95.

Я не знаком с xterm.js и всей вашей средой, чтобы сказать, можете ли вы настроить его для поддержки координат до 223 (например, изменяя кодировку символов, хотя отключение от UTF-8 также было бы глупым движением).

Правильным решением было бы добавить поддержку расширения режима мыши SGR 1006 в screen, см. https: / /savannah.gnu.org/bugs/index.php?37206. Этот новый протокол кодирует координаты с использованием ASCII-цифр, поэтому удаляет верхний предел и избавляет от проблем с кодировкой символов.

Пока они не обратятся к этому, вы можете попробовать попробовать tmux. Это более современная, более активно поддерживаемая альтернатива screen и поддерживает указанное расширение.

0
ответ дан 22 May 2018 в 16:50
  • 1
    Спасибо за информацию, @egmont! Да, это немного сложно, моя настройка. Я сам написал его с помощью нескольких библиотек, поэтому иногда мне приходится отлаживать, есть ли проблема в моем собственном коде или кто-то из них. Да, кодированные позиции SGR с открытым текстом - это то, что я использую. Таким образом, он появляется «экран» - причина моей проблемы. Есть ли репозиторий Debian / Ubuntu для обновленной версии? Интересно, почему обновление по умолчанию не скомпилировано. Я могу обойти это, но это будет проблемой для моих пользователей. Если вы переключитесь на Tmux, как мне включить его для переноса мыши? Можете ли вы сказать, что он идентифицируется как «xterm»? – jdmayfield 9 December 2017 в 15:49
  • 2
    @jdmayfield Не знаю, почему screen еще не добавил эту функцию, возможно, они не хватает ресурсов разработчика. В tmux клики за пределами 223 работают из коробки для меня (предполагая, конечно, что оба соседа tmux, то есть эмулятор хост-терминала и приложение, которое вы используете, поддерживают его тоже). Не уверен, что вы подразумеваете под словом «идентифицировать», эмуляция tmux аналогична эмуляции экрана и, соответственно, внутри tmux, у вас должен быть TERM = экран или что-то связанное, но tmux автоматически устанавливает его для вас. – egmont 10 December 2017 в 00:16
  • 3
    Эй, @egmont! Вероятно, я снова попробую tmux. «Идентифицировать вещь». Я имею в виду, что «экран» задает тип «TERM» для «экрана», в отличие от вашего фактического приложения терминала или консоли, то есть на xterm обычно TERM имеет значение «xterm-color», или что-то в этом роде, консоль linux обычно TERM - это «linux». Если вы подключили через шпатлевку, это может быть «vt100» по умолчанию (не помните, что я был в верхней части головы). «screen» имеет возможность изменить тип терминала при запуске с помощью параметра командной строки, и я также думаю, что это файл конфигурации. Если не указано явно, это TERM = screen, и я думаю, что tmux .. – jdmayfield 10 December 2017 в 10:52
  • 4
    .. и я думаю, что tmux - это TERM = tmux по умолчанию. Во всяком случае, мне нужно, чтобы он начинался с TERM = xterm-color или xterm-color16. Кроме того, параметры cli для экрана позволяют мне автоматически подключаться к последнему сеансу или автоматически запускать новый. Моя система запускает ряд команд, удаленно заканчивающихся в команде «screen», чтобы настроить некоторые локальные параметры, требующие загрузки данных с сервера, и оставляя пользователя точно там, где они остановились, без необходимости делать или знать что-либо о «экране» (или tmux, если я иду по этому маршруту). Во всяком случае, такова идея. В основном имитирует xterm в отношении сервера. – jdmayfield 10 December 2017 в 11:02
  • 5
    Спасибо за предложение, @egmont. В итоге я переключился на tmux. Чтобы заставить все работать, мне пришлось изменить тип TERM с «экрана» на «xterm-color». Это не рекомендуется из того, что я читал в документах, но он отлично работает. Путь менее багги, чем экран. Единственное, что мне действительно не нравится, - это экран с явными параметрами командной строки для идентификации себя как терминала по вашему выбору. Ни один из официально поддерживаемых подходов не работал повсеместно. Возможно, мне не хватает некоторых функций tmux, которые я не использую. Но все работает. Точно так же, как простая оболочка, но постоянные сессии! Любить это. – jdmayfield 19 January 2018 в 13:29

Унаследованный протокол мыши использует необработанные байты для каждой координаты (координата плюс 32). Таким образом, он поддерживает только координаты до 223 (223 + 32 = 255, самое большое значение, которое может содержать байты).

В некоторых ситуациях, например. когда происходит преобразование набора символов или когда какой-то компонент требует, чтобы данные, проходящие через, были действительными UTF-8, байты в диапазоне 128-255 также становятся проблематичными. Таким образом, клики работают надежно только до столбца и строки 95.

Я не знаком с xterm.js и всей вашей средой, чтобы сказать, можете ли вы настроить его для поддержки координат до 223 (например, изменяя кодировку символов, хотя отключение от UTF-8 также было бы глупым движением).

Правильным решением было бы добавить поддержку расширения режима мыши SGR 1006 в screen, см. https: / /savannah.gnu.org/bugs/index.php?37206. Этот новый протокол кодирует координаты с использованием ASCII-цифр, поэтому удаляет верхний предел и избавляет от проблем с кодировкой символов.

Пока они не обратятся к этому, вы можете попробовать попробовать tmux. Это более современная, более активно поддерживаемая альтернатива screen и поддерживает указанное расширение.

0
ответ дан 18 July 2018 в 03:59

Унаследованный протокол мыши использует необработанные байты для каждой координаты (координата плюс 32). Таким образом, он поддерживает только координаты до 223 (223 + 32 = 255, самое большое значение, которое может содержать байты).

В некоторых ситуациях, например. когда происходит преобразование набора символов или когда какой-то компонент требует, чтобы данные, проходящие через, были действительными UTF-8, байты в диапазоне 128-255 также становятся проблематичными. Таким образом, клики работают надежно только до столбца и строки 95.

Я не знаком с xterm.js и всей вашей средой, чтобы сказать, можете ли вы настроить его для поддержки координат до 223 (например, изменяя кодировку символов, хотя отключение от UTF-8 также было бы глупым движением).

Правильным решением было бы добавить поддержку расширения режима мыши SGR 1006 в screen, см. https: / /savannah.gnu.org/bugs/index.php?37206. Этот новый протокол кодирует координаты с использованием ASCII-цифр, поэтому удаляет верхний предел и избавляет от проблем с кодировкой символов.

Пока они не обратятся к этому, вы можете попробовать попробовать tmux. Это более современная, более активно поддерживаемая альтернатива screen и поддерживает указанное расширение.

0
ответ дан 24 July 2018 в 17:58

Другие вопросы по тегам:

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