Terminal: [ターミナル] VTマウスのサポート

ええ、これは現時点で既知の問題です。 マウスのサポートを2つの場所に追加する必要があります。1つはターミナルで、マウスシーケンスを合成できるようにするため、もう1つはマウスシーケンスを読み取れるようにするためです。

この問題は、最初のビットであるターミナル機能を追跡しています。

2番目のビットであるconpty部分については、＃376を参照してください。

残念ながら、これは機能しません。TMUXでマウスイベントを実行すると、複数のペインを作成する必要がなくなります。
この機能がペインの前に実装され、非常に必要とされ、ほとんどの問題を解決することを願っています

マウスのサポートは、Docker内のtmuxでも（Powershellを介して）サポートされていないことを指摘したいと思います。 これは、ターミナルに機能がないため、もちろんWSLやDockerでは機能しないためですが、先に進んで言及したいと思いました。

マウスはWSLのTMUXで動作します

マウスはwslttyで動作します： https ：

@guibirow多分それはターミナル内からのDockerの問題です。

いいえ。Dockerの問題ではありません。 これはconpty（このリポジトリ）の問題です。 マウスのサポートが必要な場合は、wslttyを試してください。

将来、ターミナルを介してtmux for Dockerで完全なマウスサポートを有効にする予定はありますか？

Dockerについて具体的にはわかりませんが、なぜ通常のターミナルと違うのかわかりません。 この問題はそれに関するものなので、注意してください！

そのため、ターミナルでWSL 1を介してtmuxをチェックしたところ、マウスもサポートされていません。 したがって、私の推測では、tmux自体は現時点ではターミナルで機能せず、Dockerの問題ではないと思います。 @guibirowが彼の側で何を見ていたかわからない。

有効にするにはコマンドを実行する必要がありますが、デフォルトでは有効になっていません。
今は持っていませんが、このように簡単ですset mouse on
来週ノートパソコンを入手したら確認する必要があります

ただし、新しいWindowsターミナルではなく、wslターミナルでのみ機能します。

ああ、やった。 ええ、それはプレーンなWSLウィンドウでうまく機能します。 新しいWindowsターミナルに埋め込まれた場合にのみ機能しません。

マウスサポートを実装する場合は、必ずSGR（1006）拡張機能も実装してください。

従来のバイトベースのプロトコルでは、最大223までの行番号と列番号のみが許可されます。これは、この番号に32が追加され、これが1バイトとして送信されるためです。 列の制限が小さすぎることは珍しくありません。 （ちなみに、列95以降、生成されたデータは7ビットクリーンではなく、有効なUTF-8ではありません。これはluitなどの変換レイヤーのエンコードで問題になります。）

SGR 1006拡張機能は、数値を10進数としてエンコードすることでこれらの問題を修正し、多くのアプリケーションでサポートされています。

この拡張が要求されていない場合、行または列が223を超えてもイベントを生成しないでください。そうしないと、オーバーフローによって厄介な結果が生じる可能性があります。 たとえば、列227をクリックすると、バイト32 + 227 = 259 = 3 = Ctrl + Cが生成されます。これは通常、実行中のプロセスにSIGINTを送信する割り込み文字です。

そう！ Conhostは実際にはDECSET 1006サポートしています！ この介在層（コンホストと通信する必要がある疑似コンソール）があるため、疑似コンソールが要求およびサポートするマウスモードの種類を選択できます。 それが1006だけではない理由はわかりません：smile：情報をありがとう！

明確にするために、中央にコンホストがあるため、次のようになります。

                                      |                 |
                 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を意味しましたか、それともこの写真のタイプミスですか？ マウス拡張機能1005および1015も存在しますが、それらの欠陥のためにほとんど使用されていません。アプリケーションが関心を持っているものではありません。

1005（xtermの2バイトUTF-8）、1015（urxvt）、および1006（xterm SGR）は、この時系列で、列番号の制限に対処するための3つの相互に排他的な拡張です。 最初の2つの欠陥に関する技術的な説明については、たとえばMidnightCommanderの問題2662および2956を参照してください。 この話は現在6〜8歳であることに注意してください。 問題のある1005や1015をサポートしているが、問題のない1006をサポートしているアプリケーションはありません。そのため、最初の2つのサポートを実装しても意味がありません（ただし、実装は非常に簡単です。 ）。

これはタイプミスの可能性があります。現在、conhostは、 1005や1006を含むがこれらに限定されない、ています。

タイプミスではありません。 申し訳ありませんが、これは、疑似コンソールシステムがクライアント側で一連のマウスモード（アプリケーションが1005、1015、レガシーVT220などを要求する）をサポートする方法を説明することを目的としていましたが、統合されたマウスモードインターフェイス（1006）をptyパイプに提示します保有者。

その図は確かに、このバグのインフラストラクチャ部分である＃376によく適合します。

@ DHowett-MSFT素晴らしい、説明してくれてありがとう！

私はこれが将来のリリースで現れるのを心待ちにしています-マウスが機能することを期待してtmuxペインをクリックし続けます:)

これについて何か進展はありますか？

@sandric特にありません-共有すべき注意事項がある場合は、必ずこのスレッドに投稿します😜

@ carlos-zamoraは今月この作業を開始します（右側の「割り当て先」フィールドと「マイルストーン」フィールドからわかるように）。 彼は、この機能の前提条件の1つである＃376の作業を開始するPR（＃3963）を持っています。

@ zadjii-msftあなたがリンクしたPRはそれがマージされたと言っていますそれは今正しいですか？

リリースノートのコメントに基づく：

疑似コンソールはマウスエスケープを処理するようになりましたが、まだあまり役に立ちません（＃3963）

（まだ）そうではないようです。 しばらくお待ちください！

@fpqcうん、そうだ

• [] Conptyは、マウスモードに入ると[シーケンス]を発行して、VTマウスモード入力をSGRシーケンス（ホバー、スクロールなど）として合成する必要があることを端末に通知します。
• [] Conhostは、conptyとHWNDの両方から同じ方法でマウス入力をVTに変換します
• []端末は[シーケンス]を消費してVTマウスモード入力を合成できます

そしてもちろん、この問題：

• []ターミナルはマウス入力シーケンスを合成します

VTマウスが有効になっている場合、テキストをコピーするにはどうすればよいですか？ VimやTmuxではできませんでした。

Shiftキーを押しながら、端末内のアプリケーションではなく、端末自体と対話します。

これはとても素晴らしいです！ ストアでこれのプレビューはいつ表示されますか？

乞うご期待

ショップからダウンロード！ マウスはVIM、htop、Tmuxでうまく機能しています。 最後に、他のすべてのWSLターミナルからマイクロソフトターミナルに移行する時が来ました！ 良い仕事をしてくれてありがとう！

PS：シフトもうまく機能しています！

マウスが機能しなかった理由を探してここに来ました... @ yveslangeからの最新のコメントを

みんなありがとう！

@ DHowett-MSFT：Micro（https://github.com/zyedidia/micro）ではマウスがまだ機能しませんが、デフォルトのPowerShellまたはcmd.exeターミナルではマウスとスクロールホイールの両方が問題なく機能します。 今のところ、マウスのサポートはWSLでのみ機能しますか？

@nicolus確かに、マウス入力は現在WSLアプリケーションでのみ機能します。 Win32バージョンのmicroを使用している場合は、まだ完全には機能しないと思います。 今のところWSLバージョンを実行することで、おそらくこれを回避できます。 ＃376は、Windowsのマウス入力に使用している問題です。

@ zadjii-msft
"commandline": "ssh [...]"カスタムプロファイルでは、マウスイベントは機能しません。 これも＃376が解決されるまで予想されますか？ 良い回避策はありますか？

編集：それとも、PowerShell / Win32-OpenSSH＃1310の結果であり、それ以外の場合は機能しますか？

これはhttps://github.com/PowerShell/Win32-OpenSSH/issues/1310の結果であり、8.xシリーズで（慈悲深く）修正されています。

@ DHowett-MSFT迅速な返信ありがとうございます。 その場合、今すぐ修正されたバージョンに手動でアップグレードするための正しい方法はありますか、それともただ待つ方が良いですか？

もちろん、リリースページから最新リリースをダウンロードしてください。