Tilix: ctrl+s on the shell prompt stops the terminal until ctrl+q is sent

[potyl]

In gnome-terminal issuing ctrl+s in the shell does nothing (as expected) and the shell can still receive commands. In tilix doing ctrl+s on the shell stops the actual shell! Keyboard input won't be read until we issue the corresponding ctrl+q.

[edubxb]

A long time ago, in a galaxy far far away...

https://en.wikipedia.org/wiki/Software_flow_control#Representation

[phw]

Thanks for identifying this. I too have this issue frequently, but until now did not know how to enable the input again. For me affected terminals where just dead and I opened a new one :(

[f2404]

It appears xfce4-terminal behaves the same way as tilix in this aspect.
@potyl What version of gnome-terminal does not swallow input for you?

[gnunn1]

gnome-terminal behaves the same as tilix does on Arch Linux. Like @phw this would happen to me from time to time in tilix and other terminal emulators and I never realized what the cause was.

It would be nice if tilix could have an option to disable it at the terminal level, but the only effective way I can see to do that is to swallow the keystrokes which could cause issues for other terminal applications. If someone has ideas on how to handle this effectively I'd be interested in hearing it.

[egmontkob]

I guess it could perform the equivalent of stty -ixon on the terminal before launching the shell. Or stty ixany also mitigates the problem.

[f2404]

@egmontkob Do you think it would be feasible to support enabling/disabling this in vte?

[potyl]

Turns out that i was using MATE Terminal 1.12.1

Gnome-terminal does show the same behavior as tilix.

[potyl]

Now that i look at what MATE Terminal 1.12.1 does it is weird. ctrl+s will freeze the output if there's data scrolling but then the next keystroke will unfreeze it.

[egmontkob]

does it is weird. ctrl+s will freeze the output if there's data scrolling but then the next keystroke will unfreeze it

That's the "stty ixany" behavior.

[egmontkob]

@f2404 I don't see why vte should do it.

[gnunn1]

I think I'll leave this to the user to manage in .bashrc or the equivalent.