Work around Windows Terminal double escape sequences encoding on our side

[unxed]

The bug itself:
microsoft/terminal#15083 (comment)

Possible solution may be like here:
microsoft/terminal#15083 (comment)

Exact commit:
magiblot/tvision@ae1a685

[Dazzar56]

Суть проблемы:

При парсинге input последовательности мы встретили вот такое:
\x1B[0;0;27;1;0;1_
27 на третьей позиции (десятичный номер \x1B ), скан-код на второй позиции нулевой.
Значит, у нас тут эвент с двойным кодированием. Эта секвенция на самом деле является началом реальной команды, которую нам и надо исполнить.
Открываем отдельный буфер и накапливаем в нем символы из третьей позиции последующих команд, пока не выгребем все . А потом весь этот буфер надо распарсить как одну команду.
например

\x1B[0;0;27;1;0;1_ 
\x1B[0;0;91;1;0;1_ 
\x1B[0;0;60;1;0;1_ 
\x1B[0;0;48;1;0;1_ 
\x1B[0;0;59;1;0;1_ 
\x1B[0;0;53;1;0;1_ 
\x1B[0;0;50;1;0;1_ 
\x1B[0;0;59;1;0;1_ 
\x1B[0;0;49;1;0;1_ 
\x1B[0;0;50;1;0;1_ 
\x1B[0;0;77;1;0;1_ 

на самом деле на до распознать как \x1B[<0;52;12M , и это уже будет нормальной командой клика левой кнопкой мыши.

\x1B[0;0;27;1;0;1_  -> \x1B
\x1B[0;0;91;1;0;1_  -> [
\x1B[0;0;60;1;0;1_  -> <
\x1B[0;0;48;1;0;1_  -> 0
\x1B[0;0;59;1;0;1_  -> ;
\x1B[0;0;53;1;0;1_  -> 5
\x1B[0;0;50;1;0;1_  -> 2
\x1B[0;0;59;1;0;1_  -> ;
\x1B[0;0;49;1;0;1_  -> 1
\x1B[0;0;50;1;0;1_  -> 2
\x1B[0;0;77;1;0;1_  -> M

Такова теория этого фикса. На практике же получилось пока так:

Я прикостылил буфер символов TTYInputSequenceParser и, как только встретил последовательность \x1B[0;0;27;1;0;1_ , накапливаю в нем 6 символов (такова длина секвенции X11-mouse event). Как только объем достигнут, отправляю этот буфер на парсинг обычным образом.
Таким образом вышло заставить работать колесо мыши в WSL, но с кликами и модификаторами сложнее: во входящих кодах тупо нет нужных символов, чтобы отличить правый клик от левого или от клика колесом.
Еще одна проблема, которую я пока не победил -- это парсинг хвоста входящих кодов как обычных символов. Сейчас они тупо сыпятся в командную строку, как если бы юзер вводил их руками.
Но в целом начало положено, нечто работающее есть.
Предложения/замечания/коммиты приветствуются.

[atolismesh]

Посмотрел в отладчике WinDbg, что происходит. Портит сообщения мышки OpenConsole.exe из Windows Terminal, а не conhost.exe. Это хорошо, так как OpenSource. Происходит примерно следующее: Одна часть программы читает события от клавиатуры, мышки и т.д., дальше расладывает их во внутреннюю очередь событий с пометкой типа события. Дальше эта очередь обрабатывается и в зависимости от выбранной эмуляции терминала преобразуется в CSI etc последовательности. Мышиные последовательности правильно преобразуются для win32input в нужный нам формат ESC[Mbxy. Пометки типа события при этом уже теряются. Это все выдается в очередь на запись. А вот дальше в отдельном потоке (второй обработчик) начинается чтение этой "очереди на запись", в которой отсутствую пометки о типе события. Обработчик видит ESC и в зависимости от выбранной эмуляции терминала преобразуется в CSI etc последовательности еще раз, считая все вводом с клавиатуры. Результаты попадают в наш терминал и far2l.
Вот так.
Нас бы спасло, если бы отключить полностью второго обработчика, так как первый уже все для нас закодировал.

[unxed]

В чате пишут, что некоторые последовательности win32-input-mode парсер kitty интерпретирует как свои. Это объясняет, почему у нас мусор в консоль в Windows Terminal валится. Впрочем, там, кажется, больше одной причины.
https://t.me/far2l_ru/16577

[unxed]

Fixed by #2085

[unxed]

FYI: fixed in Windows Terminal starting from Pre-release v1.22.2702.0.

[unxed]

Not only mouse sequences are double encoding. Additional fix is required: #2333

[unxed]

Touch #2423