Terminal: [Терминал] Поддержка мыши VT

Созданный на 8 мая 2019  ·  38Комментарии  ·  Источник: microsoft/terminal

  • Номер вашей сборки Windows: (введите ver в командной строке Windows)

10.0.18890.1000

  • Что вы делаете и что происходит: (Скопируйте и вставьте определенные команды и их вывод или добавьте снимки экрана)

Я обычно использую режим мыши в tmux с WSL для выбора окна, изменения размера панели и прокрутки, включенных в tmux.conf таким образом:

  # -- mouse support ---------------------------------------------------------                                                                                                                                                                                        
  # Enable mouse control (clickable windows, panes, resizable panes)                                                                
  set -g mouse on

Хотя это отлично работает в conhost, это не работает в Терминале; ничего не происходит, как будто события мыши никогда не доходили до tmux.

  • Что не так / что должно происходить вместо этого:

Поддержка мыши tmux (и, предположительно, других приложений, поддерживающих мышь) должна работать так же, как и в conhost.

Area-Input Area-VT Issue-Feature Product-Terminal Resolution-Fix-Committed

Самый полезный комментарий

Я с нетерпением жду, чтобы это появилось в следующем выпуске - я продолжаю нажимать на панели tmux в надежде, что мышь будет работать :)

Все 38 Комментарий

Да, на данный момент это известная проблема. Нам нужно добавить поддержку мыши в двух местах: как в терминале, чтобы иметь возможность синтезировать последовательности мыши, так и в conpty, чтобы иметь возможность читать последовательности мыши.

Эта проблема отслеживает первый бит - функциональность терминала.

Относительно второго бита, conpty, см. № 376.

К сожалению, это не работает, наличие событий мыши с TMUX откладывает необходимость иметь несколько панелей.
Я надеюсь, что эта функция будет реализована до появления панелей, она очень нужна и решит большинство проблем.

Я хотел бы отметить, что поддержка мыши также не поддерживается в tmux в Docker (через Powershell). Я знаю, что это связано с тем, что в Терминале просто нет такой функциональности, поэтому, конечно, она не будет работать в WSL или Docker, но подумал, что стоит упомянуть об этом.

мышь работает с TMUX в WSL

Мышь работает с wsltty: https://github.com/mintty/wsltty

@guibirow Может быть, это проблема с Docker из Терминала.

Нет. Это не проблема с Docker. Это проблема с conpty (это репо). Если вам нужна поддержка мыши, попробуйте wsltty.

Планируется ли в будущем включить полную поддержку мыши в tmux для Docker через Терминал?

Я не знаю конкретно о Docker, но не понимаю, почему он должен отличаться от обычного терминала. Этот выпуск именно об этом, так что следите за ним!

Итак, я только что проверил tmux через WSL 1 в Терминале, и мышь там тоже не поддерживается. Итак, я предполагаю, что сам tmux просто не работает в Терминале на данный момент и что это не проблема Docker. Не уверен, что @guibirow видел на своем конце.

Вы должны запустить команду, чтобы включить ее, по умолчанию она не включена.
У меня его сейчас нет, но это просто вот так set mouse on
Мне нужно будет подтвердить на следующей неделе, когда я получу свой ноутбук

Он работает только на терминале wsl, но не в новом терминале Windows

О, я понял. Да, он отлично работает в простом окне WSL. Он не работает только при встраивании в новый терминал Windows.

Если вы реализуете поддержку мыши, не забудьте также реализовать расширение SGR (1006).

Устаревший протокол на основе байтов допускает только номера строк и столбцов до 223, потому что к этому номеру добавляется 32, и оно отправляется как один байт. Предел столбца нередко бывает слишком маленьким. (Между прочим, начиная со столбца 95 сгенерированные данные не являются 7-битными чистыми и недействительными UTF-8, что является проблемой для кодирования уровней преобразования, таких как luit.)

Расширение SGR 1006 устраняет эти проблемы, кодируя числа в виде десятичных цифр, и поддерживается множеством приложений.

Если это расширение не запрашивается, не создавайте никаких событий, если строка или столбец превышает 223. В противном случае переполнение может иметь неприятные последствия. Например, щелчок по столбцу 227 может сгенерировать байт 32 + 227 = 259 = 3 = Ctrl + C, который обычно является символом прерывания, отправляющим SIGINT запущенному процессу.

Так! Conhost действительно поддерживает DECSET 1006 ! Поскольку у нас есть этот промежуточный уровень (псевдоконсоль, которая должна взаимодействовать с conhost), мы можем выбрать, какой режим мыши запрашивает и поддерживает псевдоконсоль. Я не вижу причин, по которым это не должно быть просто 1006 : smile: Спасибо за информацию!

Чтобы уточнить, поскольку у нас есть conhost посередине, это будет выглядеть так:

                                      |                 |
                 DECSET 1002, 1005    | Windows conhost |
+-------------+                       |  (in PTY mode)  |
|             +----------------------->                 |
| Application |                       |                 |
|             <-----------------------+                 |
+-------------+                       |                 |
                 mouse information    |                 |
                 1002 in 1005 format  |                 |
                                      |                 |
                                      +---+---------^---+
                                          |         |
                                          |         | mouse information in
                         DECSET 1002,1006 |         | SGR Extended Format
                                          |         | (1002+1006)
                                          |         |
                                      +---v---------+---+
                                      |                 |
                                      | Windows         |
                                      |  Terminal       |
                                      |                 |
                                      |                 |
                                      |                 |
                                      |                 |
                                      +-----------------+

Вы имели в виду 1005 между приложением и conhost, или это опечатка на этой картинке? Расширения 1005 и 1015 для мыши также существуют, но они почти не используются (если вообще используются) из-за их недостатков, это не то, что интересует приложения.

1005 (двухбайтовый UTF-8 xterm), 1015 (urxvt) и 1006 (xterm SGR) в этом хронологическом порядке представляют собой три взаимоисключающих расширения для устранения ограничения количества столбцов. См., Например, выпуски Midnight Commander 2662 и 2956 для технического описания недостатков первых двух. Отметим, что этой истории сейчас 6-8 лет. Я не знаю ни одного приложения, которое поддерживает проблемные 1005 и / или 1015, но не нормально 1006. Таким образом, я не вижу смысла в реализации поддержки первых двух (хотя их должно быть очень легко реализовать. ).

Это вполне может быть опечаткой, прямо сейчас conhost поддерживает множество различных режимов мыши , включая, помимо прочего, 1005 и 1006.

Это не опечатка. Извините, это было предназначено, чтобы проиллюстрировать, как система псевдоконсоли может поддерживать кучу режимов мыши на стороне клиента (приложение запрашивает 1005, 1015, устаревший VT220 и т. Д.), Но представляет унифицированный интерфейс режима мыши (1006) для канала pty. держатель.

По общему признанию, эта диаграмма лучше подходит для № 376, который является инфраструктурной частью этой ошибки.

@ DHowett-MSFT Замечательно, спасибо за разъяснения!

Я с нетерпением жду, чтобы это появилось в следующем выпуске - я продолжаю нажимать на панели tmux в надежде, что мышь будет работать :)

Есть ли в этом прогресс?

@sandric Не особо - когда есть чем поделиться, мы обязательно опубликуем в этой теме 😜

@ carlos-zamora начинает эту работу в этом месяце (как вы можете видеть из полей «назначено» и «веха» справа). У него есть PR (№ 3963) о начале работы над № 376, что является одним из предварительных условий для этой функции.

@ zadjii-msft Связанный вами PR говорит, что он был объединен. Теперь это правильно?

На основе комментария в примечаниях к выпуску:

Псевдоконсоль теперь будет обрабатывать escape-символы мыши, но пока от них не будет особой пользы (# 3963)

Кажется, нет (пока). Я слежу за обновлениями!

@fpqc Ага , правильно, этот PR был объединен. Судя по тому обсуждению, предстоит еще много работы, прежде чем это будет полностью работать в Терминале:

  • [] Conpty испускает [последовательность] при входе в любой режим мыши, чтобы сообщить терминалам, что они должны синтезировать входные данные режима мыши VT как последовательности SGR (с наведением, прокруткой и т. Д.)
  • [] Conhost переводит ввод от мыши в VT как от conpty, так и от HWND одинаково
  • [] Терминал может использовать [последовательность] для синтеза ввода режима мыши VT

И, конечно же, этот вопрос:

  • [] Терминал синтезирует последовательности ввода мыши

Как мы копируем текст при включенной VT Mouse? Я не мог этого сделать на Vim или Tmux.

Удерживайте shift, чтобы взаимодействовать с самим терминалом, а не с приложением внутри него.

Это так здорово! Когда мы увидим превью этого в магазине?

Будьте на связи

Скачал из магазина! Мышь отлично работает в VIM, htop и Tmux. Наконец, пора переходить со всех остальных WSL-терминалов на терминал Microsoft! Молодцы, ребята, и большое спасибо!

PS: shift тоже отлично работает!

Просто пришел сюда, чтобы узнать, почему мышь не работает ... прочитайте последний комментарий от @yveslange, а затем

Спасибо ребята!

@ DHowett-MSFT: Мышь по-прежнему не работает с Micro (https://github.com/zyedidia/micro), тогда как мышь и колесо прокрутки безупречно работают в терминале powershell или cmd.exe по умолчанию. Поддержка мыши сейчас работает только в WSL?

@nicolus действительно, в настоящее время ввод с помощью мыши работает только для приложений WSL. Если вы используете версию micro для Win32, готов поспорить, что она пока не работает. Вы, вероятно, могли бы обойти это, запустив версию WSL на данный момент. # 376 - это проблема, которую мы используем для ввода с помощью мыши Windows

@ zadjii-msft
События мыши не работают для меня с настраиваемым профилем с "commandline": "ssh [...]" . Ожидается ли это также до решения # 376? Есть ли хороший обходной путь?

Изменить : Или это просто результат PowerShell / Win32-OpenSSH # 1310 и будет работать в противном случае?

Это результат https://github.com/PowerShell/Win32-OpenSSH/issues/1310 , который (к счастью) исправлен в серии 8.x.

@ DHowett-MSFT Спасибо за быстрый ответ. В таком случае, есть ли разумный способ вручную обновить версию с исправлением прямо сейчас или лучше просто подождать?

Конечно, просто скачайте последнюю версию со страницы релизов!

Была ли эта страница полезной?
0 / 5 - 0 рейтинги