Re-investigate Ctrl+S pausing

[miniksa]

At some point in history, we broke Ctrl+S to pause the output in the console host. I think it was around the time that we messed with the ExtendedEditKeys stuff.

I don't have the full context on this anymore, this is just another note-to-self title only bug I had as MSFT: 17790922 that I'm porting to the outside.

We need to reinvestigate the state of Ctrl+S pausing throughout the ages. How did v1 do it? How did v2 do it over the releases of Windows 10? Do we need to reintroduce it as an option somehow?

[oising]

Ctrl+S / XOFF , ctrl+Q XON. It's just ye olde software flow control. Speaking for myself, I'd use it quite a lot with streaming logs, cat, tail etc. A vestige from old teleprinters / terminals and carried on in VT.

[oising]

Oh, and yes, methinks you should definitely reintroduce it.

[eryksun]

In NT 4, with line-input mode enabled, console output could be suspended either via the pause key (VK_PAUSE) or Ctrl-S. I'm certain Ctrl-S was chosen for the convenience of people accustomed to terminals. That said, pressing any key resumes output; it doesn't have to be Ctrl-Q since the console isn't actually a terminal responding to XOFF/XON.

Around Windows 2000 the "ExtendedEditKey" registry setting was added. If this was enabled, custom edit keys could be defined in "ExtendedEditkeyCustom". I don't think this was ever documented. If no custom mapping was defined, it used a default mapping that included the Ctrl-S -> VK_PAUSE mapping. So Ctrl-S still worked by default even if "ExtendedEditKey" was enabled.

The new console exposes "ExtendedEditKey" in the properties dialog, but it's repurposed now for "extended text selection keys". Since "ExtendedEditkeyCustom" no longer seems to be implemented beyond a vestigial CONSOLE_REGISTRY_EXTENDEDEDITKEY_CUSTOM macro in the source, I think IsPauseKey should simply return true for VK_PAUSE or Ctrl-S, which will restore the original behavior.

On a related note, in the source I see that "ExtendedEditKey" and the properties dialog set the value of global g_fEditKeys, but it seems to be unused.

[floppytree]

Do I understand it correctly that it's not only the keybinding that is missing but the whole feature of suspending the output? I would greatly appreciate the reintroduction of Ctrl-S. Sorry, if this is a developer-only forum and I'm intruding.

[HBelusca]

Please fix, as this is very useful to temporarily pause the console when e.g. an operation quickly iterates over a large number of items and displays corresponding feedback, and one wants to pause to see things appearing every now and then.

[KonstantinKhabarlak]

I think it would be nice to have full feature like in linux: suspend, move to background, move to foreground

[oising]

@KhabarlakKonstantin that is the responsibility of the shell (bash, cmd, pwsh, zsh), not the terminal (iterm2, xterm, windows terminal)

[smuuf]

Btw. I'm on Windows Terminal Preview, Version: 1.12.3472.0 (Windows 11, Insiders Dev, 22523.1000) and Ctrl+S (pause), Ctrl+Q (unpause) seems to work correctly, just as was said here #809 (comment).

Although I needed to use Google to find this exact comment to find out about this...

[Gemesys]

This is great that this functionality - that was damaged at some point - has been restored. I am training networks - on Linux, I can Ctrl-s and check output -see how things are going. But on my new Windows-11 laptop, Ctrl-s still does NOTHING. I'm glad that this has been fixed - except I find I am unable to ENABLE the fix, despite having a current machine which is updating regularly. I am guessing a registry edit is needed?
SO, what is the secret trick to actual enable Ctrl-s / Ctrl-q flow-control style pause and resume, in Windows-11 Cmd (the legacy version, of course). Thanx for any info! - M.

[oising]

@Gemesys -- unfortunately this was closed by accident, as the comments in the triggering PR say ( #15671 (comment) ). I'll reopen it, unless @lhecker or @DHowett-MSFT disagree.

[DHowett]

Great catch @oising!

[lhecker]

Since the PR was so long ago my memory of it is a bit hazy and I may be misreading the linked comment chain, but why do you believe this was not fixed? Ctrl+S for pausing works perfectly fine for me in OpenConsole and Windows Terminal 1.19 and later.

Edit: "perfectly fine" = "like old conhost". Dustin cleared me up about how XON/XOFF on other OS also properly pauses interactive prompts, etc., whereas the Windows implementation doesn't. Ctrl+S only pauses output for as long as you don't type any other characters. I wasn't aware about this difference and I apologize for that. We could consider changing this behavior. As far as I can tell it hasn't ever been different on Windows though even before ExtendedEditKeys was removed.

[oising]

Since the PR was so long ago my memory of it is a bit hazy and I may be misreading the linked comment chain, but why do you believe this was not fixed? Ctrl+S for pausing works perfectly fine for me in OpenConsole and Windows Terminal 1.19 and later.

Edit: "perfectly fine" = "like old conhost". Dustin cleared me up about how XON/XOFF on other OS also properly pauses interactive prompts, etc., whereas the Windows implementation doesn't. Ctrl+S only pauses output for as long as you don't type any other characters. I wasn't aware about this difference and I apologize for that. We could consider changing this behavior. As far as I can tell it hasn't ever been different on Windows though even before ExtendedEditKeys was removed.

Oh, well, this is news to me too :) I read the original PR as saying it wasn't implemented to spec/as expected. But it seems to function well enough for me with terminal now that I tested it.

@Gemesys Please ensure you're on the latest version of windows terminal.