mirror of
https://github.com/libuv/libuv
synced 2025-03-28 21:13:16 +00:00
843b64faf5
Windows provides the `ENABLE_VIRTUAL_TERMINAL_INPUT` flag for TTY input streams as a companion flag to `ENABLE_VIRTUAL_TERMINAL_PROCESSING`, which libuv is already setting for TTY output streams. Setting this flag lets the terminal emulator perform some of the processing that libuv already currently does for input events, but most notably enables receiving control sequences that are otherwise entirely unavailable, e.g. for bracketed paste (which the Node.js readline implementation added basic support for in https://github.com/nodejs/node/commit/87af913b66eab78088acfd). libuv currently already provides translations for key events to control sequences, i.e. what this mode is intended to provide, but libuv does not and cannot translate all such events. Since the control sequences differ from the ones that Windows has chosen to standardize on, and applications may not be expecting this change, this is opt-in for now (but ideally will be the default behavior starting in libuv v2.x, should that ever happen). Another downside of this change is that not all shells reset this mode when an application exits. For example, when running a Node.js program with this flag enabled inside of PowerShell in Windows terminal, if the application exits while in raw TTY input mode, neither the shell nor the terminal emulator reset this flag, rendering the input stream unusable. While there's general awareness of the problem that console state is global state rather than per-process (same as on UNIX platforms), it seems that applications like PowerShell aren't expecting to need to unset this flag on the input stream, only its output counterpart (e.g.4e7942135f/src/Microsoft.PowerShell.ConsoleHost/host/msh/ConsoleHost.cs (L1156)). Hence, `uv_tty_reset_mode()` is extended to reset the terminal to its original state if the new mode is being used. Refs:87af913b66Refs: https://github.com/microsoft/terminal/issues/4954