[vim/vim] cannot map CTRL-S (#6166)
lacygoill
Describe the bug
We can't map a key to C-s; it makes Vim freeze.
To Reproduce
Start Vim with this shell command:
vim -Nu NONE +'nno <c-s> :echo "hit ctrl-s"<cr>'
Press C-s: nothing happens, and Vim freezes until you press C-q.
Expected behavior
hit ctrl-s is echo'ed on the command-line, and Vim doesn't freeze.
Environment
- Vim version: 8.2 Included patches: 1-855
- OS: Ubuntu 16.04.6 LTS
- Terminal: XTerm(322)
Additional context
To avoid this pitfall, I have this line in my ~/.zshrc:
stty -ixon
It has always worked until the commit d6cd5ff. The latter has probably introduced a regression.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
lacygoill
Weird. I can't reproduce on xterm now. I'm going to make more tests.
lacygoill
Closed #6166.
lacygoill
Ok the issue happens only when modifyOtherKeys is disabled, so here is a one-liner to reproduce the issue:
vim -Nu NONE --cmd "let [&t_TI, &t_TE] = ['', '']" +'nno <c-s> :echo "hit ctrl-s"<cr>'
lacygoill
Reopened #6166.
lacygoill
I updated the original post, and here is a gif to illustrate:
Gary Johnson
> Describe the bug
>
> We can't map a key to C-s; it makes Vim freeze.
>
> To Reproduce
>
> Start Vim with this shell command:
>
> vim -Nu NONE +'nno <c-s> :echo "hit ctrl-s"<cr>'
>
> Press C-s: nothing happens, and Vim freezes until you press C-q.
>
> Expected behavior
>
> hit ctrl-s is echo'ed on the command-line, and Vim doesn't freeze.
>
> Environment
>
> • Vim version: 8.2 Included patches: 1-855
> • OS: Ubuntu 16.04.6 LTS
> • Terminal: XTerm(322)
>
> Additional context
>
> To avoid this pitfall, I have this line in my ~/.zshrc:
>
> stty -ixon
>
> It has always worked until the commit d6cd5ff. The latter has probably
> introduced a regression.
for Ctrl-S and Ctrl-Q and you'll find notes that these are both used
for flow control.
:helpgrep \cctrl.[sq]
I've had the following in my ~/.bashrc for years to avoid
fat-fingering Ctrl-S while using Vim and wondering what happened,
and also to enable forward searching in emacs-mode readline
interfaces.
stty stop undef
I've left Ctrl-Q alone, just in case. -ixon would have worked as
well.
Regards,
Gary
vim-dev ML
> Describe the bug
>
> We can't map a key to C-s; it makes Vim freeze.
>
> To Reproduce
>
> Start Vim with this shell command:
>
> vim -Nu NONE +'nno <c-s> :echo "hit ctrl-s"<cr>'
>
> Press C-s: nothing happens, and Vim freezes until you press C-q.
>
> Expected behavior
>
> hit ctrl-s is echo'ed on the command-line, and Vim doesn't freeze.
>
> Environment
>
> • Vim version: 8.2 Included patches: 1-855
> • OS: Ubuntu 16.04.6 LTS
> • Terminal: XTerm(322)
>
> Additional context
>
> To avoid this pitfall, I have this line in my ~/.zshrc:
>
> stty -ixon
>
> It has always worked until the commit d6cd5ff. The latter has probably
> introduced a regression.
for Ctrl-S and Ctrl-Q and you'll find notes that these are both used
for flow control.
:helpgrep \cctrl.[sq]
I've had the following in my ~/.bashrc for years to avoid
fat-fingering Ctrl-S while using Vim and wondering what happened,
and also to enable forward searching in emacs-mode readline
interfaces.
stty stop undef
I've left Ctrl-Q alone, just in case. -ixon would have worked as
well.
Regards,
Gary
lacygoill
As far as I can tell, this is expected behavior. Search the help
for Ctrl-S and Ctrl-Q and you'll find notes that these are both used
for flow control.:helpgrep \cctrl.[sq]
I agree, this is expected for the reasons you mentioned. What is not expected is that stty -ixon should avoid this pitfall.
I've had the following in my ~/.bashrc for years to avoid
fat-fingering Ctrl-S while using Vim and wondering what happened,
and also to enable forward searching in emacs-mode readline
interfaces.stty stop undef
I've left Ctrl-Q alone, just in case.
Yes, I have had stty -ixon in my ~/.zshrc for years for the same reason.
-ixon would have worked as well.
No, if ModifyOtherKeys is disabled, it doesn't work anymore since the commit d6cd5ff. This is why I reported the issue.
However, stty stop undef fixes the issue; thanks for the info, I'll use this command from now on.
I'll keep the issue open, because it looks like a regression; if stty -ixon worked in the past, I don't see why it couldn't work anymore.
—
You are receiving this because you commented.
lacygoill
Never mind; your solution is good. Thanks again for the quick fix.
For anyone having the same issue, replace stty -ixon with stty stop undef.
—
You are receiving this because you commented.
lacygoill
Bram Moolenaar
> > As far as I can tell, this is expected behavior. Search the help
> > for Ctrl-S and Ctrl-Q and you'll find notes that these are both used
> > for flow control.
> >
> > :helpgrep \cctrl.[sq]
>
> I agree, this is expected for the reasons you mentioned. What is not expected is that `stty -ixon` should avoid this pitfall.
>
> > I've had the following in my ~/.bashrc for years to avoid
> > fat-fingering Ctrl-S while using Vim and wondering what happened,
> > and also to enable forward searching in emacs-mode readline
> > interfaces.
> >
> > stty stop undef
> >
> > I've left Ctrl-Q alone, just in case.
>
> Yes, I have had `stty -ixon` in my `~/.zshrc` for years for the same reason.
>
> > -ixon would have worked as well.
>
>
> However, `stty stop undef` fixes the issue; thanks for the info, I'll
> use this command from now on.
>
> I'll keep the issue open, because it looks like a regression; if `stty
> -ixon` worked in the past, I don't see why it couldn't work anymore.
instead of stopping terminal output. For my I can't find a way to make
CTRL-S stop the output, also not in the shell. I thought "stty ixon"
would enable it, but it doesn't.
I can revert that patch, since it appears to cause trouble. But I would
like to understand why I can't reproduce the problem.
--
If evolution theories are correct, humans will soon grow a third
hand for operating the mouse.
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
—
You are receiving this because you commented.
lacygoill
For me I can't find a way to make CTRL-S stop the output, also not in the shell. I thought "stty ixon"
would enable it, but it doesn't.
With a recent Vim, I think you can't reproduce because you use xterm and Vim enables modifyOtherKeys by default. If that's the case, you need to disable the feature to reproduce:
vim -Nu NONE --cmd 'let [&t_TI, &t_TE] = ["", ""]'
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Otherwise, maybe you have a line in your bashrc/zshrc such as stty -ixon or stty stop undef.
I can reproduce the issue after commenting the whole ~/.Xresources file, and starting an xterm terminal from the desktop environment application launcher with the command xterm -e bash --norc --noprofile, then running the previous Vim command.
—
You are receiving this because you commented.
chdiza
I find (on macOS) that nmaping <C-s> is broken after the commit in question. My bash profile has stty -ixon in it. But I did not follow @lacygoill's procedure. I do not set &t_TI or &t_TE to empty. I have done nothing to either enable or disable modifyOtherKeys. $TERM=xterm-256color.
—
You are receiving this because you commented.
lacygoill
lacygoill
Ok, I re-open since I'm not alone.
—
You are receiving this because you commented.
chdiza
I find that if I delete stty -ixon from my bash profile, I still can't nmap <C-s>.
I thought that the whole point of the commit in question is to enable exactly that.
Please revert.
—
You are receiving this because you commented.
lacygoill
But I did not follow @lacygoill's procedure. I do not set &t_TI or &t_TE to empty. I have done nothing to either enable or disable modifyOtherKeys. $TERM=xterm-256color.
That's probably because you don't use xterm, so even though Vim sees that TERM is xterm-256color and sets the terminal options 't_TI' and 't_TE', modifyOtherKeys is not enabled. You can check by pressing C-S-v followed by C-v; if you only get a literal ^V, then the feature is disabled. And if the feature is disabled, then the commit mentioned earlier breaks stty -ixon.
Note that C-S-v is often bound to pasting the clipboard, so to test whether modifyOtherKeys is enabled you may need to temporarily disable the key binding.
In the meantime, one workaround is to replace stty -ixon with stty stop undef.
—
You are receiving this because you commented.
lacygoill
For me I can't find a way to make CTRL-S stop the output, also not in the shell. I thought "stty ixon" would enable it, but it doesn't.
I missed that part. You definitely need to disable modifyOtherKeys, but that can't explain why you can't reproduce in the shell. Maybe you have something in your terminal configuration which disables the control flow feature entirely. A quick look at man xterm lead me to the ttyModes xterm resource:
ttyModes (class TtyModes)
Specifies a string containing terminal setting keywords and the
characters to which they may be bound. Allowable keywords
include: brk, dsusp, eof, eol, eol2, erase, erase2, flush,
intr, kill, lnext, quit, rprnt, start, status, stop, susp,
swtch and weras. Control characters may be specified as ^char
(e.g., ^c or ^u) and ^? may be used to indicate delete (127).
Use ^- to denote undef. Use \034 to represent ^, since a lit‐
eral backslash in an X resource escapes the next character.This is very useful for overriding the default terminal set‐
tings without having to do an stty every time an xterm is
started. Note, however, that the stty program on a given host
may use different keywords; xterm's table is built-in.If the ttyModes resource specifies a value for erase, that
overrides the ptyInitialErase resource setting, i.e., xterm
initializes the terminal to match that value.
Just a guess, but maybe you've set the resource in the past to disable the feature.
FWIW, when I want to be sure I have an issue which can be reproduced by others, I do this:
- comment the whole
~/.Xresourcesfile and run the shell commandxrdb ~/.Xresources; the purpose is to disable any terminal config - start xterm from the desktop application launcher with the command
xterm -e bash --norc --noprofile; by using the desktop application launcher, I make sure that my current shell environment won't pollute the experiment, and--norc,--noprofiledisables any shell configuration - start Vim with
-Nu NONEto disable any Vim config
—
You are receiving this because you commented.
Bram Moolenaar
modifyOtherKeys mode by resetting t_TI and then exiting Vim. That's why
CTRL-S didn't work in the terminal.
Looking a the change again, it was done inverted: IXON was added instead
of removed. Fixing that and doing some tests shows that it is now
possible to map CTRL-S where it wasn't before, and it still stops output
when on the command line, e.g. using :grep with a lot of matches.
--
hundred-and-one symptoms of being an internet addict:
223. You set up a web-cam as your home's security system.
David le Blanc
I've been maintaining a custom branch from VIM for years just for this one line patch. I remember reading somewhere that Bram was philosophically against messing with XON/XOFF and had rejected all requests to clear IXON at startup.
I only noticed because my patch failed to apply today.
Its will be good to have this simple fix mainstream, but I suspect when Bram remembers why he avoided it in the first place, it will disappear :-)
The specific reason I patch VIM (instead of using 'stty -ixon' in my bashrc, or a vim wrapper) is because you can launch terminals inside VIM, or launch commands via '!cmd.' and CTRL-s/CTRL-q work normally there, and are disabled again when you return to VIM.
I also run VIM/BASH inside TMUX, which lets you freeze individual panes iwth Ctrl-S.
—
You are receiving this because you commented.
Bram Moolenaar
I'm not sure what you are asking for. The way it's done it should only make CTRL-S work in raw mode. When going to cooked mode, e.g. when executing a shell command, it should be as before.
if that is not see, please give a reproducible example.
—
You are receiving this because you commented.
David le Blanc
I'm not sure what you are asking for.
I'm not adding much to the discussion other than expressing both my happiness that the IXON issue is now properly fixed in the code base, and my confusion about why you chose to patch the CTRL-S issue here, and never in the past.
The way it's done it should only make CTRL-S work in raw mode.
Do you use vim on Linux? If you use it primarily on OSX or other unix (but non linux) platforms I could understand why you different behaviour.
When using a linux console, or ssh connection (not an xterm, or gnome-terminal), CTRL-S has always caused the terminal to block until CTRL-Q is pressed (standard XON/XOFF).
A simple Google of vim ixon shows discussions going back over a decade complaining that CTRL-S isn't disabled by vim, and therefore cannot be mapped to a function., which is confusing to new users who press 'ctrl-s' hoping to save a document and end up with a frozen terminal. This is also supported by the documentation which clearly stated CTRL-S would suspend output.
From your own issue tracker in 2017:
<C-s>hangs vim #1346
Example from 2010..
Wiki from 2007 explaining how to fix mappings using CTRL-S/CTRL-Q by using stty -ixon
https://vim.fandom.com/wiki/Mapping_keys_in_Vim_-_Tutorial_(Part_2)?oldid=11979
If you have literally NEVER experienced this, I'm genuinely surprised. The majority of solutions involve adding stty -ixon to startup/login scripts just as @lacygoill mentioned.
I've seen discussions on the Vim mailing lists (which I can't find with a quick search) where you clearly didn't want to change that behaviour, which is why I chose to patch it myself.
Don't get me wrong, this is a good outcome, I was just hinting (as a joke) that there was a chance you would remember why you were so adamant to keep the old CTRL-S behaviour, and revert the change.
—
You are receiving this because you commented.
Tony Mechelynck
I'm not sure what you are asking for.
I'm not adding much to the discussion other than expressing both my happiness that the IXON issue is now properly fixed in the code base, and my confusion about why you chose to patch the CTRL-S issue here, and never in the past.
The way it's done it should only make CTRL-S work in raw mode.
Do you use vim on Linux? If you use it primarily on OSX or other unix (but non linux) platforms I could understand why you different behaviour.
When using a linux console, or ssh connection (not an xterm, or gnome-terminal), CTRL-S has always caused the terminal to block until CTRL-Q is pressed (standard XON/XOFF).
IIUC, when running Vim in a Linux console, the Ctrl-S / Ctrl-Q keypresses are intercepted by the console before any program running in the console sees them, so there's nothing Vim can do. In an xterm (and maybe in gnome-terminal which I don't know as well) there exists control sequences to put the terminal in and out of raw mode, where those keypresses are passed as-is to the program.
A simple Google of
vim ixonshows discussions going back over a decade complaining that CTRL-S isn't disabled by vim, and therefore cannot be mapped to a function., which is confusing to new users who press 'ctrl-s' hoping to save a document and end up with a frozen terminal.
Anyway, the standard way to save a document in Vim is not Ctrl-S (which by default does nothing in Normal mode, and inserts a 0x13 character in Insert mode) but :write[!] [++opt] [filename] or :saveas[!] [++opt] {filename}, which can be abbreviated to :w or :sav respectively. In addition, in gvim (which IMHO is easier for beginners to use than Console Vim) there are menu items File → Save and File → Save As… which do just what you would think they do.
You can always map something else, for instance in my vimrc I map the F3 key to "save everything" like this:
map <F3> :wa|wv<CR> map! <F3> <C-O>:wa|wv<CR>
This is also supported by the documentation which clearly stated CTRL-S would suspend output.
[…]
Yes, the documentation says that, in some terminals, Ctrl-S and Ctrl-Q may be used for flow control, which makes them both unavailable for mapping, and makes Ctrl-Q unavailable as an alias for Ctrl-V (which starts Block visual in Normal mode or literalizes the next character or numeric value in Insert / Replace / Command-line modes). Other terminals, or maybe the same ones configured differently, pass these two keys to the underlying application without acting on them.
Best regards,
Tony.
—
You are receiving this because you commented.