Terminal: Re-investigate Ctrl+S pausing
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?
miniksa
All 3 comments
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
on 15 May 2019
Oh, and yes, methinks you should definitely reintroduce it.
oising
on 15 May 2019
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.
eryksun
on 16 May 2019
Related issues
mrmlnc
·
3Comments
NickITGuy
·
3Comments
DieselMeister
·
3Comments
alabuzhev
·
3Comments
mrmlnc
·
3Comments
Most helpful comment
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_PAUSEmapping. 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_CUSTOMmacro in the source, I thinkIsPauseKeyshould simply return true forVK_PAUSEor 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.