-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Conpty] Add support for mouse input #376
Comments
Hey @wez, Unfortunately, we can't just pass encoded mouse events through: since ConPTY can host standard windows console applications, the likes of which would be expecting In all other regards, though, it sounds like you're setting up the pseudoconsole correctly. Tracking: MSFT:20469462 |
@DHowett-MSFT thanks for the response! |
conpty, while it may be the best native API available for consoles built in to Windows 10, currently swallows mouse escape sequences (microsoft/terminal#376) so we need an alternative for a better windows experience. winpty appears to be a reasonably mature pty implementation, so let's try that! I tried to use winpty-sys from crates.io but it requires the installation of an external clang compiler so I used bindgen on my linux box to convert the small header file to rust and then tweaked it a bit. This commit includes that basic wrapper plus a type safe layer on top. This will require distributing the dll and an agent helper along with the wezterm.exe. This commit doesn't implement the wezterm side of the pty interface; that will be in a follow up commit.
I have nothing to add other than really wanting mouse support with ConPTY. With alacritty now having ConPTY support using alacritty + ssh + tmux is an incredible linux terminal on Windows, only mouse support is lacking now. |
This is mostly useful for folks on Windows, as you can also run `wezterm start ssh user@host some command` to run the `ssh` binary in a local pty and let it manage your ssh session. On Windows the local pty currently breaks mouse reporting (see microsoft/terminal#376) so it is desirable to avoid using a local pty if we're going to talk to a remote system. This commit makes it a bit more convenient to establish an ad-hoc ssh session with a pty on a remote host. This method uses libssh2 under the covers and thus doesn't support gssapi, which is potentially frustrating for kerberized environments, but works ok for the majority of users. There are two issues that I want to resolve in follow up work: * The TERM has to be sent very early in the channel establishment, before we "know" the TERM in the `portable-pty` interface. Will need to figure out how to specify that earlier in an appropriate way. * Similarly, if no command is specified, we should request the use of the shell subsystem but we don't have a way to capture this intend with the cmdbuilder. Will need to solve this too.
I am a heavy user of midnight commander in my Ubuntu bash shell where it works GREAT. Unfortunately, the Ubuntu shell tab in Windows Terminal 0.3.2171.0 does not appear to send ANY mouse events through to the mc application, making it extremely difficult for me to use. I was going to post a bug, but I this it would duplicate this. |
With Microsoft Terminal Preview 1.9.14450.0 and using |
Hey, it sure should have! |
For everyone following along in the audience: This shipped with ConPTY as of Terminal 1.9; eventually the change will flow back out to Windows as well. |
Woot! Woot! Woot. I've just closed gui-cs/Terminal.Gui#332 I thank you. And all Terminal.Gui users thank you. |
Thank you devs! 🎉❤️ Been following this one for a while! |
refs: microsoft/terminal#376 This also enables as the conpty layer the new win32 mode discussed in #318 wezterm itself is not able to use this mode yet.
Does it really work for you? Because it does not for me, I'm talking about pure vim on windows in windows terminal. WinTerm - 1.11.2731 It only works if I ssh to my Gentoo virtual machine and run vim there (from the WindowsTerminal or from the cmd terminal) and it also works when I start vim from MSYS2 mingw64. Left-click works for me in all the above-described environments. I have tried different settings, --clean param, and also tried to disable QuickEdit Mode. |
@DHowett @DHowett-MSFT I have noticed that the current release build of Windows 10 does not appear to have mouse support when going through VSCode's integrated console - however Windows 11 and VSCode does have mouse support in the integrated Powershell console (to ssh sessions). Is this is an oversight and will it be remedied in a future update? Also the VSCode team says the issue is with ConPTY, not VSCode. |
@rbreaves Unfortunately, they're right -- the issue is in ConPTY. Also unfortunate is that we don't get any say in what features get backported to Windows 10 Effectively, Windows development has all moved on to Windows 11. Only specific features, with leadership approval, get cherry-picked into the stable Windows 10 branches. The successive updates to Windows 10 20H1 (20H2, 21H1, 21H2) are all based on the same original code plus some "leadership approved" features backported. That's why we're working so hard to get conhost (and therefore conpty) decoupled from the operating system: so that we can give folks like you updates in a more timely fashion. |
This comment has been minimized.
This comment has been minimized.
Oddly enough I’ve mostly stopped using the built in Terminal w/ vscode. I now toggle Windows Terminal as though it’s a quake terminal which works fine either way. I didn’t do this because of the lack of proper conpty support in vscode though w/ win10. I moved on because I do a fake blur w/ glassit & just wanted more space for my code editor. I still think it’s important for them to decouple conpty - clearly leadership doesn’t understand its importance to developers. Guessing its fix looks no better than a half a dozen others they’d reject & unless you’re a dev then a good terminal experience is just “nice to have” & not a must. https://gist.github.com/rbreaves/eb7c989ecf71440e31d1f159d2a4619d |
|
Why would it? Vim was written to work w/ posix compliant shells.. aka sh, bash, zsh. Etc. |
@rbreaves That's just... not accurate at all. The shell should have nothing to do with how vim handles mouse mode. Mouse mode is a terminal feature, not a shell one. @cbartondock would you mind filing a separate issue so we can follow up with you and get to the root cause of your issue? Mouse mode should generally work for both the console and the Terminal now. There are a few bugs on the backlog IIRC, but filing a separate issue would be the easiest way for us to get to the root cause here. (without pinging the other 50 people on this thread 😝) |
The problem is in the vim itself, I have debugged it and mouse events from the scroll wheel are correctly propagated to the vim, but vim doesn't correctly handle them. It is logical because when the vim WIN32 implementation was written mouse wheel events did not work, that was years before. |
On:
Microsoft Windows [Version 10.0.17763.134]
I have implemented conpty in my terminal emulator:
https://github.com/wez/wezterm
I can successfully run
target\debug\wezterm.exe
to spawn console applications such ascmd.exe
powershell.exe
andbash
.The issue I'm seeing is that when I launch bash, either indirectly via
cmd.exe
or directly via the bash launcher, conpty seems to swallow the mouse reporting escape sequences; I don't see them being received by my terminal parser, and thusvim
has no effective mouse support despite being configured withset mouse=a
.Running the same WSL install via
wsl-terminal
does have working mouse support, andwezterm
has been my daily driver on Linux for about a year with working mouse support, so we can rule out an obvious misconfiguration withvim
and the parser inwezterm
.I've also tried
echo -e "\e[?1000h"
to manually enable mouse reporting from the shell; normally (on linux and via wsl-terminal) this causes clicks in the terminal to send data to the shell (which appears as garbage input), but when running my terminal with conpty, these are also swallowed up somewhere.Is there something special needed for the apps that I spawn into my pty to be able to work with the mouse?
In case you want to double check the key portion of the code, the relevant file is:
https://github.com/wez/wezterm/blob/master/src/winpty.rs
The flow is to
CreatePipe
a pair of pipes,CreatePseudoConsole
, and then pass that to a spawned child via the threadproc attributes, as the samples in the MSDN docs and this repo also do.The text was updated successfully, but these errors were encountered: