Show info message box when terminal is paused

[silverqx]

Would be nice to have some type of info message box that informs that the current terminal tab is paused.

Eg. KDE Konsole has this info box:

[naikrovek]

I don't think the suspension of the foreground process is a terminal thing, but a shell thing (Bash, specifically). My understanding is that Terminal doesn't know what CTRL+S means, it just gives that to the shell it's attached to, unless it is specifically bound to some action in Terminal. So, unless bash can tell the terminal emulator that the foreground process is suspended, I don't know how this would be possible.

[KalleOlaviNiemitalo]

This is about suspending output (Ctrl+S, XOFF, termios::c_cc[VSTOP]), not about suspending a process (Ctrl+Z, SIGTSTP, termios::c_cc[VSUSP]).

The console host suspends output if you press the Pause key (see InputBuffer::_HandleConsoleSuspensionEvents), but Ctrl+S does not currently have the same effect (#809). The terminal could be made to show an info message about this, but it doesn't seem very necessary because pressing almost any key resumes output anyway.

If you see Ctrl+S suspend output from Windows Terminal, then that's handled by an application or by the tty driver of a remote computer, and AFAIK there is no standard way for an application to tell the terminal that it handled the Ctrl+S keypress in this way; neither in the Win32 console API nor over a serial connection.

I don't know how KDE Konsole is implemented but I suspect that it monitors TIOCPKT_STOP and TIOCPKT_START events from a pseudoterminal device. Does that work also if you run ssh from Konsole?

[silverqx]

I'm not using it over ssh that is an extreme case, but I'm using it heavily when I'm compiling something or invoking clang-tidy or clazy and want to pause it because I need to free CPU.

I have tried it now and it works the same way in Konsole and in the wterm, so eg. if some script forks 10 processes eg. clang-tidy (invoked by run-clang-tidy.py) or clang++14 during compilation and you press CTRL+s in Konsole or Pause in wterm, then all that 10 processes are still running and finish, but no new processes will be spawned.
After unpause the execution continues and a new clang-tidy or clang++-14 processes will be spawned.

Another example that I have tried, eg. if I pause during cmake configure then everything that is currently executed finishes and nothing new is executed (many things are happening during the cmake configure step), when I unpause the rest of the output is replayed to the console and configuration continues, practically the same what I described in the paragraph above.

It looks like it only pauses a direct child and because of it the Konsole's message states that the Output was suspended.

In wterm and also in Konsole the rest of the output during this suspension is recorded and after unpause is printed to the console or replayed.

@KalleOlaviNiemitalo You are right on windows you can unpaused by any key, but it doesn't matter how it is paused or unpaused by which keys, problem is that when I pause then I don't have any visual feedback that the output is or was paused.

[zadjii-msft]

This is a cool idea, for sure, but we'd need some way for the Terminal to be able to detect that the output was suspended. If someone can figure out how to do that, then I'm all for it. I'm not sure that WSL (or ssh.exe) expose that information, however. I'm pretty sure this would end up requiring a much larger change to how signaling is done on Windows 😅

[KalleOlaviNiemitalo]

https://www.rfc-editor.org/rfc/rfc4254#section-6.8 SSH_MSG_CHANNEL_REQUEST "xon-xoff" is a way for an SSH server to ask the SSH client to handle Ctrl+S and Ctrl+Q from the terminal. I imagine the SSH client could then tell the terminal (perhaps via the console API, if you still dared to extend that) that it has done so. https://github.com/PowerShell/openssh-portable/ does not contain the "xon-xoff" string though, not even at the SSH server side.

But if this issue is only about the Pause key for which the console host already has a flag, then showing an info bar for that should be easier than doing the same for flow control with a remote computer.

[silverqx]

The wiki page about Software flow control and XON/XOFF codes.

For me is enough to detect the Pause and CTRL+S keys for pause and CTRL+Q for resume, or it can stay like it is now, so every key press resumes.

I have looked how the Konsole is doing it and it simply detects key presses in the Vt102Emulation::sendKeyEvent() handler. Main connect() is here, signals emited here and events handled in the Session::updateFlowControlState(). The XON/XOFF are sent from the event handler using the flowControlEnabled() it internally calls the Pty::flowControlEnabled().

The same can be done in wterm, I don't know if wterm uses XON/XOFF to pause the terminal but it doesn't matter. wterm already has code that is catching the PAUSE key press, much can be found by searching the pause word on GitHub here.
The code handling the pause for wterm is in the InputBuffer::_HandleConsoleSuspensionEvents().

[silverqx]

I see that more of you are writing that will be needed to detect that the terminal is suspended, this is already done in the wterm, wterm is already pausing the terminal, and nothing new code is required, he is already pausing and unpausing the terminal output!

I personally believe that only one code that is needed to write, are methods to display and hide the info box during the pause and unpause. 😎

[zadjii-msft]

<off topic showerthought> @Tyriar this might make an interesting Quick Tip for the vscode terminal, if there's a good way of wiring that up. IK when I was first getting the commandline ropes I'd definitely instinctively Ctrl+S in vim and be super confused when it stopped working.

[Tyriar]

Now that you say that, by default we support ctrl+s but ctrl+q has an override so this will essentially brick terminals in vscode 🙈. I think this would be better as a "status" on the terminal tab which changes the icon/color of the tab