Terminal: [Conpty]マウス入力のサポートを追加

ねえ@wez 、
残念ながら、ConPTYはマウスレポート（または、ホストされているアプリケーションからの_マウスレポートの要求_）を転送しません。 これを追跡するバックログアイテムがあり、すぐに取得したいと考えています。

残念ながら、エンコードされたマウスイベントを渡すことはできません。ConPTYは標準のWindowsコンソールアプリケーションをホストできるため、 MOUSE_EVENT ReadConsoleInput介して受信されると予想されます。いくつかの翻訳を行う必要があります。

ただし、他のすべての点では、疑似コンソールを正しく設定しているようです。

追跡： MSFT：20469462

@ DHowett-MSFTの回答ありがとうございます！
マウスのレポートがまだないのは少し残念ですが、それでも残りのptyのものが可能になっているのは良いことです！

ConPTYでのマウスサポートが本当に必要なこと以外に追加するものはありません。 alacrittyがalacritty + ssh + tmuxを使用してConPTYをサポートするようになったため、Windows上の素晴らしいLinuxターミナルであり、現在はマウスのサポートのみが不足しています。

私はUbuntubashシェルで真夜中の司令官を頻繁に使用しています。 残念ながら、Windowsターミナル0.3.2171.0のUbuntuシェルタブは、マウスイベントをmcアプリケーションに送信していないようで、使用するのが非常に困難です。 バグを投稿するつもりでしたが、これは重複します。

私の使用では、vimとtmuxを上手に体験するには、マウスイベントを送信することが最も重要です。

これに対する私のサポートをここにドロップするだけで、少しコンテキストが加わります。 この1か月間、デュアルブートを停止し、Windows10インサイダービルドの「高速」リングをプライマリパーソナルマシンとして使用し始めました。 その上で、wsl2が完全に機能し、x410が完全に機能し、Microsoftターミナルが正常に機能し、ビジュアルスタジオコードwsl2相互運用機能が完全に機能し、explorer.exe相互運用機能が完全に機能しています。

このマウス入力チケットは、wsl2 / microsoft terminalを、別のパーティション/開発ボックスを持つための合理的な代替品と呼ぶことを妨げる唯一のことです。 ここのいくつかのスポットはオープンソースなので、 /devどこかからマウスデバイスの入力を確認する方法についての指針はありますか？

しかし、このすべてに感謝します！ そうでなければ本当に好きです:)

マウスのサポートはとても甘く、tmuxを使用している人は誰もがそれをしなくてもうまくいくかもしれないと言ったり、要求したりするためのもう1つの投票。

マウスサポートを有効にしてください😄

@ DHowett-MSFT、ナグについて申し訳ありませんが、これをすぐに修正する計画はありますか？ 他の問題に割り当てられたラベル/優先度を確認しますが、これはそれらの1つではないため、確認するだけです。 ありがとうございました。

@damnskippy優先度は、

バグのように「修正」できれば、それがいいのですが、修正以上のものが必要です。

更新していただきありがとうございます。 あなたの仕事はありがたいです。

私はあなたがここでやっていることが大好きです、私はそうします、しかし私たちがマウスのサポートを得るまで、私たちはこの端末を別の端末で補完しなければならず、この端末の目的をいくらか打ち負かします。

これのない真夜中の司令官は悪夢です。

コミュニティの誰かがWindowsターミナルで実行できるDosBoxアドインとプロファイルを作成する場合など、一般にマウス入力が役立つ可能性があります。

私はvimのヘビーユーザーです。 マウスのサポートが恋しいです😢

@ cinnamon-msftブログの更新を読んだばかりですが、チームは今年の終わりまでに1.0を目指しているようです。 これは、年末までにマウスのサポートを受けることを意味しますか？ もしそうなら、それは現在積極的に取り組んでいますか？

これは、年末までにマウスのサポートを受けることを意味しますか？

たぶん、しかしハードコミットはありません。 ソフトウェアが完了するまでにかかる時間を見積もるのは、P == NPを証明するのと同じくらい難しいです。 これがなければ、端末は1.0対応にはならないでしょう。

もしそうなら、それは現在積極的に取り組んでいますか？

現在はありません。 タスクには誰も割り当てられていません。通常、チームの誰かがタスクを噛んだときに、自分で割り当てます。

好奇心から、これを行うために必要なものはすべてここにありますか？ 野心的な（読む：クレイジーな）開発者はそれを引き受けてPRをすることができますか？

確かに、野心的な人は絶対に自分でこれを試すことができます。 どこから始めますか？

まず、いくつかのスコープの概要を説明しましょう。 マウス入力には多くの作業が必要になるため、最初は小さな作業から始めて、完全な解決策に到達するために少しずつ作業するのが最善です。 最初に作業を開始する必要があるのは、 SGRでエンコードされた単純なマウスの上下シーケンスです。 マウスホイールイベントで作業し、その後ホバーすることもできますが、クリックすると_ほとんどの_ユースケースが解決されると思います。

InputStateMachineEngine.cppを確認することからInputStateMachineEngineは、conptyを介して送信された入力を解析し、それをINPUT_RECORD変換する役割を果たします。 進取の気性に富んだ若い開発者は、それらのマウスシーケンスも解析できるようにそのクラスを変更し、それらをINPUT_RECORD変換したいと思うでしょう。 あなたが持ってたらINPUT_RECORD sのを、呼び出しInteractDispatch::WriteInput 。 これにより、これらのINPUT_RECORDが入力バッファに追加されます。 それらが入力バッファに入ると、通常、接続されているコンソールクライアントアプリケーションに配信されます。

私が気をつけたいこと：

• conhostは、マウス入力モードでない限り、MouseEventsをバッファにまったく挿入しない可能性があります。 その場合は、これらのシーケンスも無視する必要があります。
• VTからのマウス入力が必要なアプリは、 INPUT_RECORDのストリームではなく、文字のストリームを取得します。 コンホストのある時点で、接続されたアプリケーションがVTマウスモードの場合、これらのマウスINPUT_RECORDを文字のストリームに変換しようとします。 マウスイベントがバッファにある前にその変換を行うと、VTアプリケーションでは上記の実行が機能しない可能性があります（読み取り： wsl ）。 その場合は、 InputStateMachineEngineによって生成されたマウスイベントに対して、マウスINPUT_RECORDからVTでエンコードされたマウスイベントへの変換が手動で行われるようにする必要があります。
  
  
  
  • もっと調べてみると、それは事実のように見えます。 残念ながら、ウィンドウによって開始されたイベントのマウス入力のみを変換します。 このコードを参照してください：
    
    https://github.com/microsoft/terminal/blob/2c8b3243dca0c48dd05ecd7b420a7a03b3e19c93/src/interactivity/win32/windowio.cpp#L113 -L129
    
    terminalMouseInput.HandleMouseは、クライアントアプリケーションのVTシーケンスを合成しますが、残念ながら、ウィンドウプロシージャからのみ呼び出されます。 したがって、 InputStateMachineEngineを呼び出す方法を何らかの方法で公開する必要があります（ InteractDispatch新しいメソッドを介して）。そのメソッドが失敗した場合は、適切なINPUT_RECORD生成します。
  
  
  • 技術的には、誰かが代わりにterminalMouseInput.HandleMouse呼び出しをInputBufferの読み取りに移動し、読み取られたときにINPUT_RECORD正しく変換しようとする可能性がありますが、それはもっと複雑かもしれません。
  
  

この問題にどのように対処しますか？ マウスは、古いWindowsコンソールで完全に機能します。 これが修正されるまで、コンソールを使い続ける必要があるということですか？

VTマウスのサポートが必要な場合は、はい。

これを調査している可能性のあるコミュニティメンバー（/ cc @SamuelEnglard！）への参考までに、これを行うための開発チームの作業を正式に予約しました。 私たちはあなたのつま先を踏んでいないことを願っています！

考えてみましたが、自分の時間を予約できなかったので完璧です笑！

リモート開発拡張機能を備えたVSCodeで遊んでいたところ、その統合端末が実際にtmuxのマウスモードをサポートしていることがわかりました。 パネルの選択、ウィンドウの選択、パネルのサイズ変更、スクロールホイールはすべての作業をサポートします。 私はこれらのプロジェクトに不慣れなので、ターミナルがオープンソースのVS Codiumの一部であり、出発点として使用できるかどうかわかりません...これが本当に有用な情報でない場合は申し訳ありません

これを調査している可能性のあるコミュニティメンバー（/ cc @SamuelEnglard！）への参考までに、これを行うための開発チームの作業を正式に予約しました。 私たちはあなたのつま先を踏んでいないことを願っています！

@ DHowett-MSFT @ zadjii-MSFTは素晴らしいされている本明細書の他の場所、この問題に関するあなたのコミュニケーションを@bitcrazed。 これは、ソフトウェアの構築にコミュニティをうまく関与させるための模範であり、それが示しています。 あなたのチーム（console / WSL / msft-linux）は、Windows（nix以外）をインストールする私のビジネスに対して個人的に責任があります。 傑出した仕事を続けてください🥇

@thinkjrs親切な言葉をありがとう。

そして、ターミナル、Cascadia Code、WSLなどの質問、アイデア、プルリクエストを実行およびテスト/ファイルする/送信するコミュニティのすべての人に心から感謝します。私たちが作業を優先し、計画するとき、あなたのフィードバックは私たちに直接影響しますおよび設計機能。

コミュニティのために、そしてコミュニティとともにこれらの機能を構築すると言ったとき、私たちは冗談ではありませんでした😜

プロセスは何ですか？ WSLに機能するマウスはありますか？ つまり、 tmuxパネル切り替え、クリックしてweechatとirssiでチャネル/サーバーを変更、 (n)vimクリック、 aptitudeクリック、 htopクリックなど

プロセスは何ですか？ WSLに機能するマウスはありますか？ つまり、 tmuxパネル切り替え、クリックしてweechatとirssiでチャネル/サーバーを変更、 (n)vimクリック、 aptitudeクリック、 htopクリックなど

@dmxt現在、私はすべての端末オプションの中で最も互換性のあるwslttyを使用しています。 これらの機能のいくつかが登場したら、ターミナルに切り替えることを楽しみにしています。

プロセスは何ですか？ WSLに機能するマウスはありますか？ つまり、 tmuxパネル切り替え、クリックしてweechatとirssiでチャネル/サーバーを変更、 (n)vimクリック、 aptitudeクリック、 htopクリックなど

@dmxt現在、私はすべての端末オプションの中で最も互換性のあるwslttyを使用しています。 これらの機能のいくつかが登場したら、ターミナルに切り替えることを楽しみにしています。

私はあなたのコメントに同意します。過去数年間にWindows用に一般に知られているすべてのターミナルエミュレーターを試した後、執筆時点では、wslttyが最高です。 彼らの公式レポも素晴らしいです、彼らは私がスピーディーに始めるための素晴らしいガイドを持っています。 機知に富んだものでこれ以上のことを求めることはできませんでした。さまざまなワークフローやツール全体で問題が発生することなく、完全なマウスサポートが得られました。

I / Oのわずかな遅延に気づきましたが、これがWSL1システムのボトルネックだと思います。 私はベアメタルLinuxを使用しており、マウス入力で0ミリ秒の遅延があります。

@dmxt @offero XShell（実験的な機能からの実際のコマンドライン、またはsshからWSLへ）で成功しました-参考までに、マウスのサポートなどがあります。 また、マウスのサポートがひどく必要なアプリは、真夜中の司令官とマイクロエディターです。

ConEmuでどのように解決されるか見てください

正確にこれがいつ実装されるかについてのロードマップまたはタイムラインはありますか？ リリースするのは非常に重要な機能のようです。 これが解決されずにv1.0がリリースされているのは、私にはちょっと驚きです。 最近のバージョン管理は何の意味もないと思います。

私が知る限り、Windowsターミナルの最新のMicrosoft Storeバージョンの@kvnxiaoマウス入力は（少なくともVimでは）サポートされています

@ fat0troll私が知る限り、これは間違いなくset mouse=a vimでも、マウス入力は古いコンホストでは機能しますが、Windows Terminal1.0.1401.0では機能しません。

set nocompatible
syntax on
set number
set mouse=a
set backspace=indent,eol,start

そのvim設定で、vimのウィンドウ内をクリックすると、クリックした場所にカーソルが移動します。 1.0.1401.0、Windowsビルド18368.836（これに影響がある場合）。

@ kvnxiaoOpenSSH_For_Windows_7.7を使用していると思います。 マウスモードで動作しないバグ（8.xで解決）があります。

これは、マウス入力を受け取りたいすべてのVTアプリケーションに明示的に実装されています。

最近のバージョン管理は何の意味もないと思います。

不親切である必要はありません。

vimに関しては、Windows用に構築されたneovimをWindowsの実行可能ファイルとして使用してみました。 他の人がマウスサポートがvimで機能すると言っている場合（たとえば、ssh / wslなどを介して）、私はあなたを疑っていませんが、これは「完全な」サポートがまだ存在しないことを示しています。質問：

コンホストが現在可能なものと比較して、「完全な」マウスサポートのロードマップには何が残っているでしょうか。

私は、WTを介してマウス入力をサポートする（そしてコンホストで動作する）汎用端末ベースのアプリケーションを起動したいという観点から話しています。 たとえば、Windows実行可能ファイルとして直接構築された複数のテキストベース/ターミナルユーザーインターフェイスアプリケーションを実行します。 これらは、ダブルクリックして実行すると正常に機能し、conhostを使用しますが、Windows Terminalを介して実行すると、表示されたテキストをマウスで選択するだけで終了します。

@niklaskorz私のような人々がこのトピックに関連する質問をしているときに、前述のコメントに賛成と反対の投票をすることのポイントは何ですか？それはまだ解決されていないかもしれませんし、そうでないかもしれません。

あなたは完全に正しいです。 この作業項目は、任意の端末からマウスイベントを受信するWin32コンソールアプリケーション用であると正しく識別されており、「端末1.x」（マイ​​ルストーン）が予定されています。これは、現在から2.0までの間に取り組むことを示しています。 それ以上にきめ細かい見積もりはありません。

説明してくれてありがとう！ このワークアイテムが1.0で競合できなかったことは少し悲しいですが、競合するのを心待ちにしています。長く待たされないことを願っています😀。

FIWW、あなたがそれを知らなかった場合、新しいPowershell Out-ConsoleGridView （https://github.com/PowerShell/GraphicalTools）はこれのキラーテストケースです。 そこにあるマウス関連の追跡バグを参照してください： https ：

Terminal.Gui （https://github.com/tig/gui.cs）の上に構築されています。

さらに、 Terminal.Gui用の新しいサンプルアプリを作成しました。これを使用して、WTでのマウスサポートのテストに使用できます。

本当に楽しみにしています！

この問題を修正するのに役立つ方法はありますか？ これは、Terminal.Gui（https://github.com/tig/gui.cs）で構築されたGUIコンソールアプリにとっては本当に残念です。

@ kvnxiaoOpenSSH_For_Windows_7.7を使用していると思います。 マウスモードで動作しないバグ（8.xで解決）があります。

これは、マウス入力を受け取りたいすべてのVTアプリケーションに明示的に実装されています。

最近のバージョン管理は何の意味もないと思います。

不親切である必要はありません。

組み込みのopensshを最新バージョンに更新するにはどうすればよいですか？

@ kvnxiaoOpenSSH_For_Windows_7.7を使用していると思います。 マウスモードで動作しないバグ（8.xで解決）があります。
これは、マウス入力を受け取りたいすべてのVTアプリケーションに明示的に実装されています。

最近のバージョン管理は何の意味もないと思います。

不親切である必要はありません。

組み込みのopensshを最新バージョンに更新するにはどうすればよいですか？

このブログ投稿（chocolateyからのOpensshインストール）で説明されているものを探していると思います： https ：//blog.frankfu.com.au/2019/03/21/moving-from-windows-1809s-openssh-to-

OpenSSH_For_Windows_7.7を使用していると思います。 マウスモードで動作しないバグ（8.xで解決）があります。

これは、マウス入力を受け取りたいすべてのVTアプリケーションに明示的に実装されています。

@DHowettこのコンテキストから、 OpenSSH_for_Windows_8.0p1, LibreSSL 2.6.5を使用すると機能することが期待されるように聞こえますか？

ターミナルプレビュービルドを使用して、tmuxマウスモードが有効になっているUbuntuマシンにSSHで接続していますが、マウス入力はターミナル自体を制御しているだけのようです。

サーバーをOpenSSH8.0にアップグレードしようとしましたが、それも役に立ちませんでした。

この問題はまだそのようなものが機能するのを妨げていますか？

ああ、8.xのxは1かもしれません。8.0ビルドがリリースされたことに気づいていませんでした。

ああ、8.xのxは1かもしれません。私は彼らが8.0ビルドをリリースしたことに気づいていませんでした。

私はそれを試してみます。

できます！ すごい、ありがとう！

私はこの問題を理解し始めました。

残念ながら、MSはまだWindowsターミナルにWin32APIのマウス入力機能を実装していません。
（VTエスケープシーケンスのみがサポートされています。）

アプリケーションでReadConsoleInputWとPeekConsoleInputWを置き換えようとしました
Windowsターミナルでマウスを操作します。

まず、次のコードを実行します。

SetConsoleMode(hin,  ENABLE_VIRTUAL_TERMINAL_INPUT);
SetConsoleMode(hout, ENABLE_PROCESSED_OUTPUT | ENABLE_VIRTUAL_TERMINAL_PROCESSING);
char *vt_mouse_input_enable_cmd  = "\x1b[?1000h\x1b[?1003h\x1b[?1006h";
DWORD written;
WriteConsoleA(hout, vt_mouse_input_enable_cmd, strlen(vt_mouse_input_enable_cmd), &written, NULL);

次に、マウス入力をVTエスケープシーケンス（sgr-1006）として受信できます（例： \x1b[<0;10;20M ）。

しかし、別の問題が発生しました。

一部のキー入力（矢印キーなど）もVTエスケープシーケンスとして受信されます（例： \x1b[A ）。

これらの不要なVTエスケープシーケンスをwin32APIのキーイベントに変換しようとしました。
しかし、これは不完全です。
（仮想キーコードと仮想スキャンコードが何気なくゼロになるなど）

私のコードはここにあります。
https://gist.github.com/Hamayama/6add968870269f2426716fad79724b31
（PDC_read_console_input_wとPDC_peek_console_input_wは代替関数です。）

マウス入力以外のVTエスケープシーケンスを無効にするメソッドが必要です。

例えば

char *vt_key_input_disable_cmd = "\x1b[?9XXXl";
DWORD written;
WriteConsoleA(hout, vt_key_input_disable_cmd, strlen(vt_key_input_disable_cmd), &written, NULL);

また

SetConsoleMode(hin, ENABLE_VIRTUAL_TERMINAL_MOUSE_INPUT_ONLY);

しかし、これは将来的には間違った考えかもしれません...

src/terminal/parser/InputStateMachineEngine.cpp: 391 （SGR VTシーケンスのINPUT_RECORDへの変換）にはマウスの動きの追跡がないことがわかりました。

つまり、ターミナルはConPTYのVTシーケンスを送信しますが、ConPTYはマウスボタンの状態のみを監視します。 マウス座標の変更は無視されます。

src/terminal/parser/InputStateMachineEngine.cpp: 391 ：

success = _UpdateSGRMouseButtonState(id, firstParameter, buttonState, eventFlags);
success = success && _WriteMouseEvent(parameters.at(1), parameters.at(2), buttonState, modifierState, eventFlags);

マウス入力の現在のサポート状態では、次のオプションが可能です。

座標追跡を追加すると、マウスの動きが従来のコンソールアプリケーションで機能し始めます。

src/terminal/parser/InputStateMachineEngine.hpp: 172 ：

+ size_t _mouseColumn = 0;
+ size_t _mouseLine = 0;

src/terminal/parser/InputStateMachineEngine.cpp: 391 ：

- success = success && _WriteMouseEvent(parameters.at(1), parameters.at(2), buttonState, modifierState, eventFlags);
+ auto mouseColumn = parameters.at(1).value_or(0);
+ auto mouseLine = parameters.at(2).value_or(0);
+ auto isMoved = mouseColumn! = _mouseColumn || mouseLine! = _mouseLine;
+ if (isMoved)
+ {
+     _mouseColumn = mouseColumn;
+     _mouseLine = mouseLine;
+ }
+ success = (success || isMoved) && _WriteMouseEvent(mouseColumn, mouseLine, buttonState, modifierState, eventFlags);

注：従来のコンソールアプリケーションを起動する前に、SGR形式でマウスの追跡を要求する必要があります。

Windows PowerShell

PS C:\Users> [char]0x1b + "[?1003;1004;1006h"

コマンド・プロンプト

C:\Users> echo Ctrl + [ [?1003;1004;1006h

パラメーター

• 1003 -ANY_EVENT_MOUSE_MODE
• 1004 -シーケンスをConPTYを介してターミナル自体に転送するためのサポートされていないモード（例： 1001または9999 ）
• 1006 -SGR_EXTENDED_MODE

その結果、ターミナルはConpTYへのマウスイベントの送信を開始します。ConpTYは、従来のコンソールアプリケーション用にINPUT_RECORDの生成を開始します。

良いキャッチ。 これをサポートするために実際に移動するときに、それを修正する必要があります：smile：