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?
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.
Oh, and yes, methinks you should definitely reintroduce it.
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.
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_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 thinkIsPauseKey
should simply return true forVK_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.