Enable Windows support by using a conpty-proxy

[xhcoding]

The conpty-proxy launches processes through conpty and redirects their input/output to its own stdin and stdout.

[Sbozzolo]

I don't have access to windows machines. Would anyone be interested in testing this?

[Master-Hash]

I don't have access to windows machines. Would anyone be interested in testing this?

I confirm it works, but documentation and config need polish.

e.g. The package relies on conpty_proxy.exe, whose path seems not configurable (default: the same path as vterm.el, see https://github.com/xhcoding/emacs-libvterm/blob/master/vterm.el#L1465-L1467).

A working snapshot:

[xhcoding]

I don't have access to windows machines. Would anyone be interested in testing this?

I confirm it works, but documentation and config need polish.

e.g. The package relies on conpty_proxy.exe, whose path seems not configurable (default: the same path as vterm.el, see https://github.com/xhcoding/emacs-libvterm/blob/master/vterm.el#L1465-L1467).

A working snapshot:
I've added a new variable to specify the path to conpty_proxy.exe

[kiennq]

This is also working fine for me.
I have an issue where the module can't be loaded with native-comp Emacs in Windows, but it's resolved by using a module without dependency on lib-vterm dll.

Here is my branch if anyone wants to try out https://github.com/kiennq/emacs-libvterm. It also includes a pre-built binary that can be tried out immediately.

[leuven65]

This is also working fine for me. I have an issue where the module can't be loaded with native-comp Emacs in Windows, but it's resolved by using a module without dependency on lib-vterm dll.

Here is my branch if anyone wants to try out https://github.com/kiennq/emacs-libvterm. It also includes a pre-built binary that can be tried out immediately.

Maybe try to install the pre-built version of libvterm by pacman, instead of building it from src repo by cmake ExternalProject_add.
Not sure if they use same src version, maybe the pre-built version contains some extra fixing?
https://github.com/msys2/MINGW-packages/commits/master/mingw-w64-libvterm

Such as,
mingw64: pacman -S mingw-w64-x86_64-libvterm
ucrt64: pacman -S mingw-w64-ucrt-x86_64-libvterm

[kiennq]

Maybe try to install the pre-built version of libvterm by pacman

Somehow it doesn't work for native comp version of Emacs on Windows. The module loading kept failing.

[kiennq]

@xhcoding, when I use interactive command line tool (ex: copilot-cli or python) inside vterm, sometimes it spawns a new conpty process and hangs Emacs. Do you know if that's fixable?

[kiennq]

@xhcoding, when I use interactive command line tool (ex: copilot-cli or python) inside vterm, sometimes it spawns a new conpty process and hangs Emacs. Do you know if that's fixable?

I found out the reason why. It's because vterm creates a new conpty process and wait for its result when doing resizing. Since the overhead is high, it makes the whole Emacs slow as long as the vterm is in display. Also, if the new conpty process is stuck the whole Emacs will hang without be able to quit using Ctrl + g (as I observed).

1. It's better to just call the external process without waiting for its result (notify) and use the passed width, height in Emacs immediately. Adding a debounce on creating process is also nice since it lowers the overhead of creating a new process in Windows as well.
2. Alternatively, we can use call-process and accept-process-output to wait for external process to finish, that will allow us at least to quit with Ctrl + g when Emacs stuck.

Here is a fix using approach 1 kiennq@0e0e179

[lehaworker]

@xhcoding, when I use interactive command line tool (ex: copilot-cli or python) inside vterm, sometimes it spawns a new conpty process and hangs Emacs. Do you know if that's fixable?

I found out the reason why. It's because vterm creates a new conpty process and wait for its result when doing resizing. Since the overhead is high, it makes the whole Emacs slow as long as the vterm is in display. Also, if the new conpty process is stuck the whole Emacs will hang without be able to quit using Ctrl + g (as I observed).

1. It's better to just call the external process without waiting for its result (notify) and use the passed width, height in Emacs immediately. Adding a debounce on creating process is also nice since it lowers the overhead of creating a new process in Windows as well.
2. Alternatively, we can use call-process and accept-process-output to wait for external process to finish, that will allow us at least to quit with Ctrl + g when Emacs stuck.

Here is a fix using approach 1 kiennq@0e0e179

Your version works! Laggy, but usable.

[leuven65]

Here is a fix using approach 1 kiennq@0e0e179

Nice fixing!

One remark:
Maybe it is better to define "vterm--conpty-proxy-resize-timer" as buffer local variable, as same as "vterm--process", as each vterm session needs to have its own timer.

Some small adapt:
leuven65@aa1dcb5
leuven65@a6ac8ea

[kiennq]

Maybe it is better to define "vterm--conpty-proxy-resize-timer" as buffer local variable, as same as "vterm--process", as each vterm session needs to have its own timer.

Nice catch.

[heheda123123]

Three weeks have passed. Is there any progress?

[maksim-brylev]

Three weeks have passed. Is there any progress?

You can use it right now, today, and then upstreaming shouldn't bother you that much.