Terminal: [Conpty] 마우스 입력 지원 추가

안녕하세요 @wez ,
유감스럽게도 ConPTY는 마우스 보고서(또는 호스팅된 응용 프로그램에서 _마우스 보고 요청_)를 전송하지 않습니다. 우리는 이것을 추적하는 백로그 항목이 있어 곧 얻을 수 있기를 바랍니다.

불행히도 인코딩된 마우스 이벤트를 다음을 통해 전달할 수는 없습니다. ConPTY는 표준 Windows 콘솔 애플리케이션을 호스팅할 수 있기 때문에 MOUSE_EVENT ReadConsoleInput 를 통해 들어올 것으로 예상합니다. 번역을 좀 해야 합니다.

그러나 다른 모든 측면에서 의사 콘솔을 올바르게 설정하고 있는 것처럼 들립니다.

추적: MSFT:20469462

@DHowett-MSFT 답변 감사합니다!
마우스 보고 기능이 아직 없다는 것이 조금 아쉽긴 하지만, 나머지 pty 항목이 지금 가능하다는 것은 여전히 ​​좋은 일입니다!

ConPTY로 마우스 지원을 정말로 원하는 것 외에 추가할 것이 없습니다. alacritty + ssh + tmux를 사용하여 ConPTY를 지원하는 alacritty와 함께 Windows의 놀라운 Linux 터미널은 이제 마우스 지원만 부족합니다.

나는 훌륭하게 작동하는 Ubuntu bash 셸에서 자정 사령관을 많이 사용합니다. 불행히도 Windows 터미널 0.3.2171.0의 Ubuntu 셸 탭은 mc 응용 프로그램을 통해 마우스 이벤트를 보내지 않는 것으로 나타나 사용하기가 매우 어렵습니다. 나는 버그를 게시하려고했지만 이것은 이것을 복제 할 것입니다.

내 사용을 위해 마우스 이벤트를 보내는 것은 vim 및 tmux에 대한 좋은 경험을 위해 가장 중요합니다.

여기에 대한 지원과 약간의 컨텍스트를 생략합니다. 지난 달에 저는 이중 부팅을 중단하고 Windows 10 내부자 빌드 "빠른" 링을 기본 개인 컴퓨터로 사용하기 시작했습니다. 나는 wsl2가 완벽하게 작동하고, x410이 완벽하게 작동하고, microsoft 터미널이 훌륭하게 작동하고, Visual Studio 코드 wsl2 interop이 완벽하게 작동하고, explorer.exe interop이 완벽하게 작동합니다.

이 마우스 입력 티켓은 별도의 파티션/개발 상자가 있는 합리적인 대체품으로 wsl2/microsoft 터미널을 호출하지 못하게 하는 거의 유일한 것입니다. 여기 일부 지점은 오픈 소스이므로 /dev 어딘가에서 마우스 장치 입력을 보는 방법에 대한 포인터가 있습니까? 아니면 그냥 멈춰야 합니까?

그래도 이 모든 것에 감사드립니다! 다른 점은 정말 마음에 들어요 :)

마우스 지원이 매우 달콤하고 tmux를 사용하는 모든 사람이 그리워할 것이라고 말/요청하기 위해 한 번 더 투표합니다.

마우스 지원을 활성화해주세요 😄

@DHowett-MSFT, 잔소리에 대해 죄송합니다. 이 문제를 곧 고칠 계획이 있습니까? 다른 문제에 할당된 레이블/우선순위를 보지만 이것은 그 중 하나가 아니므로 확인만 하면 됩니다. 감사합니다.

@damnskippy 우선순위는 인박스 Windows 콘솔 호스트에서 수정해야 하는 사항에 할당됩니다(내부 버그 마감으로 인해). 이것은 _거대한_ 기능이며(그리고 적절하게 조정된 사양이 필요함) v1.0에 필요하다는 것을 알고 있지만 현재 적극적으로 작업하지 않습니다.

버그처럼 "수정"할 수 있다면 정말 좋겠지만 수정 이상의 것이 필요합니다.

업데이트해주셔서 감사합니다. 귀하의 작업에 감사드립니다.

나는 당신이 여기서 하는 일을 사랑하지만, 우리가 마우스 지원을 받을 때까지 우리는 이 터미널의 목적을 다소 무너뜨리는 다른 터미널로 이 터미널을 칭찬해야 합니다.

이것이 없는 미드나잇 커맨더는 악몽입니다.

일반적으로 마우스 입력은 커뮤니티의 누군가가 Windows 터미널에서 실행할 수 있는 DosBox 추가 기능 및 프로필을 만드는 경우 유용할 수 있습니다.

저는 vim을 많이 사용합니다. 마우스 지원도 그리워요 😢

방금 @cinnamon-msft 블로그 업데이트를 읽었습니다. 팀이 올해 말까지 1.0을 목표로 하고 있는 것 같습니까? 이것은 우리가 올해 말까지 마우스 지원을 받는다는 것을 의미합니까? 그렇다면 현재 활발히 진행되고 있습니까?

이것은 우리가 올해 말까지 마우스 지원을 받는다는 것을 의미합니까?

아마도, 하지만 하드 커밋은 없습니다. 소프트웨어가 완료되는 데 걸리는 시간을 추정하는 것은 P==NP를 증명하는 것만큼 어렵습니다. 이것이 없으면 터미널은 1.0 준비가 되지 않을 것이라고 말할 수 있습니다.

그렇다면 현재 활발히 진행되고 있습니까?

현재는 아닙니다. 아무도 작업에 할당되지 않으며 일반적으로 팀의 누군가가 작업을 중단하면 스스로 할당합니다.

호기심에 여기에서 이 작업을 수행하는 데 필요한 모든 것이 있습니까? 야심 찬 (읽기 : 미친) 개발자가 그것을 받아 PR을 할 수 있습니까?

물론, 야심 찬 사람은 스스로 이것을 시도할 수 있습니다. 어디서부터 시작해야 할까요?

먼저 범위를 간략히 설명하겠습니다. 마우스 입력으로 해야 할 일이 많기 때문에 작게 시작하여 완전한 솔루션에 도달하기 위해 조각을 작업하는 것이 가장 좋습니다. 우리가 작업해야 하는 첫 번째 작업은 단순한 SGR 인코딩 마우스 업/다운 시퀀스라고 생각합니다. 우리는 마우스 휠 이벤트에 대해 작업할 수 있고 그 후에 마우스를 가져갈 수 있지만 클릭하면 _대부분의_ 사용 사례를 해결할 수 있을 것입니다.

InputStateMachineEngine.cpp를 살펴보는 것으로 시작하십시오. InputStateMachineEngine 는 conpty를 통해 전송된 입력을 구문 분석하고 이를 INPUT_RECORD 로 변환합니다. 진취적인 젊은 개발자는 해당 마우스 시퀀스를 구문 분석하고 INPUT_RECORD 로 변환할 수 있도록 해당 클래스를 수정하려고 합니다. INPUT_RECORD 가 있으면 InteractDispatch::WriteInput 호출합니다. 그러면 INPUT_RECORD 가 입력 버퍼에 추가됩니다. 입력 버퍼에 있으면 연결된 콘솔 클라이언트 응용 프로그램에 정상적으로 전달됩니다.

내가 주의할 점:

• conhost는 마우스 입력 모드가 아니면 MouseEvents를 버퍼에 전혀 삽입하지 않을 수 있습니다. 그렇다면 이러한 시퀀스도 무시해야 합니다.
• VT에서 마우스 입력을 원하는 앱은 INPUT_RECORD 스트림이 아니라 문자 스트림을 받습니다. 연결된 응용 프로그램이 VT 마우스 모드인 경우 conhost의 특정 지점에서 해당 마우스 INPUT_RECORD 를 문자 스트림으로 변환하려고 시도합니다. 마우스 이벤트가 버퍼에 있기 _전에_ 번역을 수행하면 위의 작업이 VT 응용 프로그램에서 작동하지 않을 수 있습니다(읽기: wsl ). 그런 경우, 우리는 마우스에서 번역 있는지 확인해야합니다 INPUT_RECORD VT-인코딩 마우스 이벤트가에 의해 생성 된 마우스 이벤트를 수동으로 수행 InputStateMachineEngine .
  
  
  
  • 좀 더 들여다보면 그런 경우가 있는 것 같다. 불행히도 창에 의해 시작된 이벤트에 대한 마우스 입력만 번역합니다. 이 코드를 참조하십시오.
    
    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 @SamuelEnglad!)을 위해 공식적으로 개발팀에서 작업을 예약했습니다. 나는 우리가 당신의 발을 밟지 않기를 바랍니다!

생각해봤는데 제 시간이 너무 완벽해서 예약을 못했어요 ㅋㅋㅋㅋ

나는 원격 개발 확장으로 VSCode를 가지고 놀고 있었고 그 안에 통합 터미널이 실제로 tmux에서 마우스 모드를 지원한다는 것을 발견했습니다! 패널 선택, 창 선택, 패널 크기 조정 및 스크롤 휠이 모든 작업을 지원합니다. 저는 이 프로젝트를 처음 접하기 때문에 터미널이 오픈 소스 VS Codium의 일부이고 시작점으로 사용할 수 있는지 모르겠습니다... 이것이 정말 유용한 정보가 아니라면 죄송합니다.

참고로 이 문제를 조사하고 있는 커뮤니티 구성원(/cc @SamuelEnglad!)을 위해 공식적으로 개발팀에서 작업을 예약했습니다. 나는 우리가 당신의 발을 밟지 않기를 바랍니다!

@DHowett-MSFT @zadjii-msft @bitcrazed 여기와 다른 곳에서 이 문제에 대한 귀하의 커뮤니케이션은 환상적이었습니다. 이것은 귀하의 소프트웨어를 구축하는 데 커뮤니티를 성공적으로 참여시키는 본보기이며 보여줍니다. 귀하의 팀(console/WSL/msft-linux)은 개인적으로 Windows(비 nix)를 설치하는 제 비즈니스에 대한 책임이 있습니다. 뛰어난 작업을 계속하십시오 🥇

@thinkjrs 좋은 말씀 감사합니다.

터미널, Cascadia 코드, 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를 사용 중이며 마우스 입력에 0ms의 대기 시간이 있습니다.

@dmxt @offero XShell(실험적 기능의 실제 명령줄 또는 WSL로의 ssh)로 성공했습니다. 참고로 마우스 지원 등이 있습니다. 또한 마우스 지원이 심하게 필요한 앱은 미드나잇 커맨더 와 마이크로 에디터입니다.

ConEmu에서 어떻게 해결되는지 살펴보십시오.

이것이 정확히 언제 구현될 것인지에 대한 로드맵이나 타임라인이 있습니까? 출시하기에 상당히 중요한 기능인 것 같습니다. v1.0이 이 문제가 해결되지 않고 출시되고 있다는 사실이 조금 놀랍습니다. 요즘은 버저닝이 의미가 없는 것 같아요.

내가 말할 수 있는 한 최신 Microsoft Store 버전의 Windows 터미널 마우스 입력에서

@fat0troll 내가 말할 수 있는 한, 이것은 확실히 사실이 아닙니다. set mouse=a 있는 vim에서도 마우스 입력은 이전 conhost에서 작동하지만 Windows Terminal 1.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(이에 영향을 미치는 경우).

@kvnxiao 나는 당신이 OpenSSH_For_Windows_7.7을 사용하고 있다고 추측할 것입니다. 마우스 모드에서 작동하지 못하게 하는 버그가 있습니다(8.x에서 해결됨).

마우스 입력을 받으려는 모든 VT 응용 프로그램에 대해 이것을 명시적으로 구현했습니다.

요즘은 버저닝이 의미가 없는 것 같아요.

불친절할 필요는 없습니다.

vim과 관련하여 Windows용으로 빌드된 neovim을 Windows 실행 파일로 사용하여 시도했습니다. 다른 사람들이 vim에서 마우스 지원이 작동한다고 말한다면(예: ssh / wsl 등을 통해), 나는 당신을 의심하지 않지만 이것은 "완전한" 지원이 아직 존재하지 않는다는 것을 보여줍니다. 질문:

현재 conhost가 할 수 있는 것과 비교하여 "완전한" 마우스 지원을 위한 로드맵에 무엇이 남아 있습니까?

나는 WT를 통해 마우스 입력을 지원하는(그리고 conhost에서 작업하는) 일반 터미널 기반 응용 프로그램을 시작하려는 관점에서 말하고 있습니다. 예를 들어, Windows 실행 파일로 직접 빌드된 여러 텍스트 기반/터미널 사용자 인터페이스 응용 프로그램을 실행합니다. conhost를 사용하는 실행을 위해 두 번 클릭하면 제대로 작동하지만 Windows 터미널을 통해 실행하면 표시된 텍스트를 마우스로 선택하기만 하면 됩니다.

@niklaskorz 나 같은 사람들이 이 주제와 관련하여 여전히 해결되지 않을 수도 있는 관련 질문이 있을 때 앞서 언급한 의견을 찬성하거나 반대하는 의미가 무엇입니까?

당신이 완전히 맞습니다. 모든 터미널에서 마우스 이벤트를 수신하는 Win32 콘솔 응용 프로그램용으로 올바르게 식별한 이 작업 항목은 "터미널 1.x"(마일스톤)로 예정되어 있으며, 이는 현재와 2.0 사이에 이를 처리하고자 함을 나타냅니다. 이보다 더 세밀한 견적은 없습니다.

설명 감사합니다! 이 작업 항목이 1.0에 대해 경쟁할 수 없다는 것이 조금 아쉽지만 언제 경쟁할 수 있는지 간절히 기다리고 있으며 너무 오래 기다리지 않기를 바랍니다 😀.

FIWW, 알지 못하는 경우를 대비하여 새로운 Powershell Out-ConsoleGridView (https://github.com/PowerShell/GraphicalTools)이 이에 대한 킬러 테스트 케이스입니다. https://github.com/PowerShell/GraphicalTools/issues/95에서 마우스 관련 추적 버그를 참조하십시오.

Terminal.Gui (https://github.com/tig/gui.cs) 위에 구축되었습니다.

또한 WT에서 생동감 있게 마우스 지원을 테스트하는 데 사용할 수 있는 Terminal.Gui 용 샘플 앱을 새로 만들었습니다.

정말 기대됩니다!

이 문제를 해결하는 데 도움을 줄 수 있는 방법이 있습니까? 이것은 Terminal.Gui(https://github.com/tig/gui.cs)로 빌드된 GUI 콘솔 앱에 대한 진정한 실패입니다.

@kvnxiao 나는 당신이 OpenSSH_For_Windows_7.7을 사용하고 있다고 추측할 것입니다. 마우스 모드에서 작동하지 못하게 하는 버그가 있습니다(8.x에서 해결됨).

마우스 입력을 받으려는 모든 VT 응용 프로그램에 대해 이것을 명시적으로 구현했습니다.

요즘은 버저닝이 의미가 없는 것 같아요.

불친절할 필요는 없습니다.

내장 openssh를 최신 버전으로 업데이트하려면 어떻게 해야 합니까?

@kvnxiao 나는 당신이 OpenSSH_For_Windows_7.7을 사용하고 있다고 추측할 것입니다. 마우스 모드에서 작동하지 못하게 하는 버그가 있습니다(8.x에서 해결됨).
마우스 입력을 받으려는 모든 VT 응용 프로그램에 대해 이것을 명시적으로 구현했습니다.

요즘은 버저닝이 의미가 없는 것 같아요.

불친절할 필요는 없습니다.

내장 openssh를 최신 버전으로 업데이트하려면 어떻게 해야 합니까?

이 블로그 게시물(초콜릿에서 Openssh 설치)에 설명된 것을 찾고 있는 것 같습니다. https://blog.frankfu.com.au/2019/03/21/moving-from-windows-1809s-openssh-to- openssh-휴대용/

나는 당신이 OpenSSH_For_Windows_7.7을 사용하고 있다고 추측할 것입니다. 마우스 모드에서 작동하지 못하게 하는 버그가 있습니다(8.x에서 해결됨).

마우스 입력을 받으려는 모든 VT 응용 프로그램에 대해 이것을 명시적으로 구현했습니다.

@DHowett 이 컨텍스트에서 OpenSSH_for_Windows_8.0p1, LibreSSL 2.6.5 를 사용하면 작동하는 것처럼 들립 니까?

터미널 미리보기 빌드를 사용하여 tmux 마우스 모드가 활성화된 Ubuntu 시스템에 SSH로 연결하지만 내 마우스 입력은 여전히 ​​터미널 자체만 제어하는 ​​것 같습니다.

또한 서버를 OpenSSH 8.0으로 업그레이드하려고 시도했지만 도움이 되지 않았습니다.

이 문제가 여전히 그런 종류의 작업을 차단하고 있습니까?

아, 8.x의 x 는 1일 수 있습니다. 8.0 빌드를 출시했는지 몰랐습니다.

아, 8.x의 x는 1일 수 있습니다. 8.0 빌드를 출시했는지 몰랐습니다.

한 번 해보겠습니다.

효과가있다! 놀랍습니다. 감사합니다!

나는 이 문제를 이해하기 시작했다.

안타깝게도 MS는 아직 Windows 터미널에서 Win32 API의 마우스 입력 기능을 구현하지 않습니다.
(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 이스케이프 시퀀스를 win32 API의 키 이벤트로 변환하려고 했습니다.
그러나 이것은 불완전합니다.
(가상 키 코드와 가상 스캔 코드는 자연스럽게 0이 되는 등)

내 코드가 여기에 있습니다.
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 s로 변환)에서 마우스 움직임을 추적하지 않는다는 것을 발견했습니다.

즉, 터미널은 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 형식으로 마우스 추적을 요청해야 합니다.

윈도우 파워쉘

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로 보내기 시작하고 클래식 콘솔 응용 프로그램에 대해 INPUT_RECORD 생성을 시작합니다.

좋은 캐치. 이 :smile을 지원하기 위해 실제로 이동할 때 이를 수정해야 합니다.