I open vim from inside tmux and I would like particular keystroke sequences: CTRL-F5 and CTRL-F6 passed onto the underlying vim instance and not intercepted by tmux. That is, these two keystroke sequences have been configured in my .vimrc
At present, these keystroke sequences seem to capitalize the word under the cursor due to tmux's interception of them and I do not want this behaviour.
On a related note, is it possible to check what a particular keystroke is mapped to do in tmux?
Related
Vim windows navigation breaks for me once I perform these steps:
from (bash in my case) terminal open vim (8.1) in terminal mode
>vim -c ":term ++curwin"
then from the vim-terminal open vim
>vim
From inside vim, open a new split window
:sp
try navigating
<C-w><C-w>
and it doesn't work
Using Vim as a terminal emulator and Vim again inside of it, I see. Are you trying to create a black hole?
Anyway, if the built-in terminal allowed this it would function as a keyboard trap, effectively making it impossible to move the focus to another (host) Vim window.
It's really a classic case of the host capturing a keystroke and preventing the hosted program to receive it. Pretty much like screen using <C-a> as leader and thus preventing you from incrementing the number under the cursor in Vim.
And just like screen that lets you do <C-a>a to send an actual <C-a> to the hosted program, Vim's built-in terminal lets you do <C-w>. to send an actual <C-w>.
Therefore, you can do <C-w>.<C-w>. to achieve your goal (however misguided it might be).
See :help terminal-typing.
Lately, when using Vim in tmux over ssh, sometimes something happens where Vim starts ignoring all my mappings that start with Ctrl: for instance <C-P>, which I have bound to the CtrlP plugin. Instead, Vim runs the builtin action (in this case, moving lines upward in the file). I don't doubt that the correct keypress is reaching Vim, as it uses the correct builtin action associated with <C-P> (using :send-keys to send ctrl-p from tmux also causes the builtin <C-P> in vim to run, instead of the mapping).
All my mappings not involving the control key still work. For instance, I can do this:
nnoremap p :echo "test"<cr>, and pressing p echoes test
But then immediately after,
nnoremap <c-p> :echo "test"<cr>, and pressing CTRL-P doesn't echo test, it moves the cursor up one line.
Restarting Vim always fixes the issue, but at some point, something I do causes the problem to surface again. I've been working mostly in tmux through ssh lately, so I'm not 100% sure if either one of those are the problem (although I think I recall this happening once in Vim in tmux not over ssh), but as mentioned above, I believe using send-keys directly from tmux as a test is ensuring that vim is getting the actual ctrl-p keycode. As well, <C-V><C-P> in insert mode does actually insert ^P.
Note that although I've used ctrl-p here as an example, since it's a key I actually use a lot in practice, this applies to any control key mapping.
Is there some kind of Vim state I don't know about that's causing this to happen? Is this likely a terminal problem? What are my next steps?
When you enter vim, it "clears" the screen. Upon exiting, it "restores" the original contents.
I understand one can use \x1b[2J to clear the console and reset the cursor position, but this will overwrite terminal contents.
I assume Vim uses ncurses under the hood, in which case I suppose the better question is how ncurses does this, but how is it done?
Regarding the answer by #Keith Thompson — not exactly:
vim does not use the screen optimization of ncurses which sends smcup and rmcup automatically. Rather, it is a termcap application. It follows a convention used by most (not all) termcap applications. There are some implementations of vi which do not for instance (on IRIX64 perhaps).
as for "most terminals" — actually, xterm look-alikes are a small part of the terminal database (even counting variations, less than 10%). Rephrase that to something like "the most common terminal emulators on Linux.
the terminal does not save and restore the screen contents. Instead, it switches between two screens (in xterm's documentation "normal" and "alternate"). In xterm for instance, one can always switch between the two using a menu entry. The xterm FAQ Why doesn't the screen clear when running vi? gives more detail.
for better context, note that smcup is an (obscure) abbreviation for set-mode-cursor-positioning, or start cursor-positioning mode. (also cursor-addressing). The r in rmcup means "reset" (and m means "mode"). set/reset have different connotations from save/restore; with the latter the user is led to believe that the values can be stacked up.
Most terminal emulators are able to save and restore the contents of the screen.
The terminfo codes for this are smcup to enter full-screen mode and rmcup to leave it. (The older termcap codes are ti and te.)
If these capabilities are enabled in the terminfo database, any program that uses ncurses will print the smcup string on entry, and the rmcup string on exit.
On the system I'm using at the moment, the strings are (with \E representing the Escape character):
smcup: \E7\E[?1;47h
rmcup: \E[2J\E[?1;47l\E8
This restores the previous contents of the screen as well as the cursor position.
The specific meanings of the sequences (for xterm) are documented here:
smcup:
\E7 Save Cursor
\E[?1;47h Application Cursor Keys; Use Alternate Screen Buffer
rmcup:
\E[2J Erase screen
\E[?1;47l Application Cursor Keys; Use Normal Screen Buffer
\E8 Restore Cursor
(This assumes I'm understanding the use of the semicolon correctly; I'm not 100% sure of that.)
Is it possible for the terminal to detect ⇧ Shift+Enter↵ or Ctrl+Enter↵ keypresses?
I am trying to configure vim to do key mappings that use these sequences, and while they work fine in gvim, they don't seem to work in any terminal console.
The curious thing is that although Ctrl+Enter↵ is not detected in vim, mapping Enter↵ to Esc maps properly, but then pressing Ctrl+Enter↵ behaves like Enter↵!
Some terminals send <NL> when <C-Enter> is pressed. This is equivalent to sending <C-J>.
To find out what your terminal does with <Shift-Enter>, <Ctrl-Enter> and <Enter>, go to your terminal, type <Ctrl-V> (similar to sykora's suggestion for vim), and type in the sequence you're interested in.
Using gnome-terminal, I get the following:
<Enter> : ^M
<S-Enter> : ^M
<C-Enter> : <NL>
Looking at man ascii indicates that ^M gives the <CR> sequence.
The answer is that it depends on the terminal, and there's an easy way to check.
Gvim runs its own manager for keystroke handling and so can pick up all the various key combinations. Vim is reliant on the specific terminal for passing on the particular keypress, so keyhandling is only as good or varied as the terminal is.
One way you can find out whether you can do what you want to do is to use the key to find out what is inserted. eg Type:
:<C-V><C-Enter>
ie actually type in the combination you want to press after having typed the combination Control-V. After that do the same thing for enter, ie
:<C-V><Enter>
If they yield the same code, then the terminal interprets both key combinations as the same keycode, and you can't bind them without messing with the terminal.
In my terminal (urxvt), Control-Enter, Shift-Enter and Enter (by itself) all produce the ^M character, meaning I can't map one without mapping the other. The same goes for Control-Tab and Control-I, and Control-Space and Control-#
EDIT: Use C-Q instead of C-V for Windows.
Is it possible for the terminal to detect ⇧ Shift+Enter↵ or Ctrl+Enter↵ keypresses?
I am trying to configure vim to do key mappings that use these sequences, and while they work fine in gvim, they don't seem to work in any terminal console.
The curious thing is that although Ctrl+Enter↵ is not detected in vim, mapping Enter↵ to Esc maps properly, but then pressing Ctrl+Enter↵ behaves like Enter↵!
Some terminals send <NL> when <C-Enter> is pressed. This is equivalent to sending <C-J>.
To find out what your terminal does with <Shift-Enter>, <Ctrl-Enter> and <Enter>, go to your terminal, type <Ctrl-V> (similar to sykora's suggestion for vim), and type in the sequence you're interested in.
Using gnome-terminal, I get the following:
<Enter> : ^M
<S-Enter> : ^M
<C-Enter> : <NL>
Looking at man ascii indicates that ^M gives the <CR> sequence.
The answer is that it depends on the terminal, and there's an easy way to check.
Gvim runs its own manager for keystroke handling and so can pick up all the various key combinations. Vim is reliant on the specific terminal for passing on the particular keypress, so keyhandling is only as good or varied as the terminal is.
One way you can find out whether you can do what you want to do is to use the key to find out what is inserted. eg Type:
:<C-V><C-Enter>
ie actually type in the combination you want to press after having typed the combination Control-V. After that do the same thing for enter, ie
:<C-V><Enter>
If they yield the same code, then the terminal interprets both key combinations as the same keycode, and you can't bind them without messing with the terminal.
In my terminal (urxvt), Control-Enter, Shift-Enter and Enter (by itself) all produce the ^M character, meaning I can't map one without mapping the other. The same goes for Control-Tab and Control-I, and Control-Space and Control-#
EDIT: Use C-Q instead of C-V for Windows.