Terminal: Reinvestigar Ctrl+S pausando
Em algum momento da história, quebramos Ctrl+S para pausar a saída no host do console. Acho que foi mais ou menos na época em que mexemos com as coisas do ExtendedEditKeys.
Eu não tenho mais o contexto completo sobre isso, este é apenas outro bug que eu tinha como MSFT: 17790922 que estou portando para o exterior.
Precisamos investigar novamente o estado do Ctrl+S pausando ao longo dos tempos. Como v1 fez isso? Como a v2 fez isso nos lançamentos do Windows 10? Precisamos reintroduzi-lo como uma opção de alguma forma?
miniksa
Todos 3 comentários
Ctrl+S / XOFF, ctrl+Q XON. É apenas o controle de fluxo de software antigo. Falando por mim, eu usaria bastante com streaming de logs, cat, tail etc. Um vestígio de teleimpressoras/terminais antigos e continua no VT.
oising
em 15 mai. 2019
Ah, e sim, acho que você definitivamente deveria reintroduzi-lo.
oising
em 15 mai. 2019
No NT 4, com o modo de entrada de linha ativado, a saída do console pode ser suspensa por meio da tecla de pausa ( VK_PAUSE ) ou Ctrl-S. Estou certo de que Ctrl-S foi escolhido para a conveniência de pessoas acostumadas a terminais. Dito isso, pressionar qualquer tecla retoma a saída; não precisa ser Ctrl-Q, pois o console não é realmente um terminal respondendo a XOFF/XON.
Por volta do Windows 2000, a configuração de registro "ExtendedEditKey" foi adicionada. Se isso estiver ativado, as chaves de edição personalizadas podem ser definidas em "ExtendedEditkeyCustom". Acho que isso nunca foi documentado. Se nenhum mapeamento personalizado foi definido, ele usou um mapeamento padrão que incluiu o mapeamento Ctrl-S -> VK_PAUSE . Portanto, Ctrl-S ainda funcionava por padrão, mesmo que "ExtendedEditKey" estivesse ativado.
O novo console expõe "ExtendedEditKey" na caixa de diálogo de propriedades, mas agora é reaproveitado para "chaves de seleção de texto estendidas". Como "ExtendedEditkeyCustom" não parece mais ser implementado além de uma macro residual CONSOLE_REGISTRY_EXTENDEDEDITKEY_CUSTOM na fonte, acho que IsPauseKey deve simplesmente retornar true para VK_PAUSE ou Ctrl-S, que restaurar o comportamento original.
Em uma nota relacionada, na fonte, vejo que "ExtendedEditKey" e a caixa de diálogo de propriedades definem o valor de global g_fEditKeys , mas parece não ser usado.
eryksun
em 16 mai. 2019
Questões relacionadas
carlos-zamora
·
3Comentários
dev-logan
·
3Comentários
mrmlnc
·
3Comentários
ghvanderweg
·
3Comentários
TayYuanGeng
·
3Comentários
Comentários muito úteis
No NT 4, com o modo de entrada de linha ativado, a saída do console pode ser suspensa por meio da tecla de pausa (
VK_PAUSE) ou Ctrl-S. Estou certo de que Ctrl-S foi escolhido para a conveniência de pessoas acostumadas a terminais. Dito isso, pressionar qualquer tecla retoma a saída; não precisa ser Ctrl-Q, pois o console não é realmente um terminal respondendo a XOFF/XON.Por volta do Windows 2000, a configuração de registro "ExtendedEditKey" foi adicionada. Se isso estiver ativado, as chaves de edição personalizadas podem ser definidas em "ExtendedEditkeyCustom". Acho que isso nunca foi documentado. Se nenhum mapeamento personalizado foi definido, ele usou um mapeamento padrão que incluiu o mapeamento Ctrl-S ->
VK_PAUSE. Portanto, Ctrl-S ainda funcionava por padrão, mesmo que "ExtendedEditKey" estivesse ativado.O novo console expõe "ExtendedEditKey" na caixa de diálogo de propriedades, mas agora é reaproveitado para "chaves de seleção de texto estendidas". Como "ExtendedEditkeyCustom" não parece mais ser implementado além de uma macro residual
CONSOLE_REGISTRY_EXTENDEDEDITKEY_CUSTOMna fonte, acho queIsPauseKeydeve simplesmente retornar true paraVK_PAUSEou Ctrl-S, que restaurar o comportamento original.Em uma nota relacionada, na fonte, vejo que "ExtendedEditKey" e a caixa de diálogo de propriedades definem o valor de global
g_fEditKeys, mas parece não ser usado.