2

I've successfully disabled Ctrl+S in terminal using instructions here. However, if I launch a terminal programs (namely terminal vim) from "outside the terminal", Ctrl+S still freezes the screen.

What I mean by "outside the terminal":

  • Using a keyboard shortcut to run something like kitty -e vim to open vim in terminal
  • Using vimserver to launch terminal vim from the file manager, which in the end pretty much does the same as above

Is there a way around this? (Other than unlearning the habit of constantly saving with Ctrl+S ;)

(There are reasons I cannot and don't want to use gVim. Running stty -ixon from inside vim doesn't work, and I'm sure there are good reasons why not – I'm not really familiar with stty yet...)

1
  • You can also try undefining the stop character: stty stop undef. I don't know if this will persist in more situations.
    – meuh
    Sep 27 at 10:07
4

Add this to your ~/.vimrc:

silent !stty -ixon

If that creates problems with a non-tty vim like gvim (no idea, not able to test it), try this:

silent !test -t 0 && stty -ixon

It looks like they decided to make -ixon the default in recent versions of vim, so this is soon going to stop being an issue with vim (notice that the original patch from the originator of the issue was untested garbage, but the final patch got it right).

Generally (with other programs), there's no general solution ;-)

xterm has a ttyModes resource (and -tm option) which can be used to set the initial modes, but which does not support -ixon. I don't think that kitty has even that.


Running stty -ixon from inside vim doesn't work

That's because vim restores the initial (usually non-raw) state of the terminal before running external commands via :!command, and then changes it back to raw mode upon replying to the "Press ENTER or type command" prompt, so any changes performed by command are lost.


As an extra note, the common folklore spread on this site & elsewhere (that ^S/^Q are just an anachronistic carryover from the time before less and tmux, etc) is wrong; software flow control is something you must use on any serial line without RTS/CTS out-of-band signaling (especially on a line with high baud rate), and something that is totally useless on any kind of virtual tty.

See this for the kind of problems that just blindly turning IXON off (in that case by the ssh client on the local tty) may cause for people using actual serial lines to connect to their devices. Most programs which call cfmakeraw (or duplicate it exactly) are bound to fail in the same way (script(1) is the first one that comes to mind).

2
  • @Quasímodo Thanks, almost forgot! The silent !resize > /dev/null is to fix glitches you mention here? I haven't encountered them but I guess it doesn't hurt being preemtive.
    – krumeluu
    Sep 28 at 19:01
  • Thanks for clearing that. Also apparently resize is an xterm thing
    – krumeluu
    Sep 29 at 15:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.