I have a few keystrokes (like <M-[>) imap'd to executing some actions in my .vimrc, e.g.
imap <M-[> <C-o>:silent !audtool --playback-seek-relative -3<CR>
for seeking in audacious while typing (for transcripting recorded speech). I wanted to do the same for Czech keyboard layout, which happens to have ú (u-acute) in that position. So I tried the obvious
imap <M-ú> <C-o>:silent !audtool --playback-seek-relative -3<CR>
which does not work. What is the solution here? Tried :help key-notation and google without success. A solution only working in gvim (and not in terminal) is fine.
Vim has an ancient method to handle input – it is represented as a byte (character) queue, not as a keystroke sequence queue. I guess, the character <M-ú> (yes, it should be a char) just does not exist, like as <C-1> doesn’t. You can make sure of it by pressing <C-v><M-ú> in input mode – a plain ú or nothing would be typed. So there is no way to map <M-ú> to something either.
But! Hence Vim is not well to handle different external layouts than basic QWERTY by design, it provide an his own (internal) mechanism for supporting second layout.
If you do :set keymap=czech, you would be able to switch input language inside Vim by <C-6>, and forget about mapping mess – in mappings <M-[> (as well as z, 2, etc) would mean one key chord in both layouts.
BTW, this is actually an only way to adequately use Vim for a language which has a layout that is completely different than QWERTY (e. g. Cyrillic).
Related
While using Vim under Linux Mint 20.2 (with NumLock off), when I hit the NumPad center key (5), a line is inserted above the current line, a capital E appears, and I am left in Insert mode. I often mistakenly hit the 5 key when trying to navigate using the NumPad cursor keys, and I would love to redefine the NumPad 5 to do nothing. I've tried remapping the key in .vimrc (using noremap <Esc>[E <Esc>, for example), but it has no effect. Note, the ANSI sequence produced when I press the NumPad5 is \033[E
FYI, I have TERM=xterm-256color.
Note: this answer generally talks about the numpad in a no-numlock context. All numbers on the numpad can be mapped when numlock is on by using <k0>...<k9>. References to the mapability of keys is therefore in a no-numlock context
Note, the ANSI sequence produced when I press the NumPad5 is \033[E
Vim doesn't see it that way.
On my system (Mint 20.2 with Cinnamon under X11), no-numlock 5 produces ^[OE. That O is very important to the observed behavior. o means "go to a new line under and enter insert mode", and O means the exact same thing, but to a new line above. The next E is then interpreted as an insert mode character, because Vim.
Moreover, esc is represented as ^[, so for mapping purposes, you only need <esc>. This point is easier to demonstrate in Vim:
^[ is additionally treated as a single character. If you want to play around with this, pop into insert mode and press <C-v>. The next key(bind) you press will be printed literally to the screen
This means what you actually want is:
nnoremap <Esc>OE <nop>
Note that I'm not sure how terminal input processing applies here; this may only hold for certain terminals, or even only apply to X11.
Another trick in general here, and a way to make sure the keycode is correct for your terminal, is that you can type :nnoremap , and then press Ctrl+v+Numpad 5. This will give you the exact keycode as Vim sees it, which you then can map to whatever you have planned.
If you do this in gVim, however, you'll find that numpad 5 without numlock doesn't actually produce a keycode detectable by gVim. This presumably means it can't be mapped (unless there's some way I just don't know about - if there is, please prove me wrong). But because it doesn't spew out a terminal code, there's the added benefit of not needing to remap it for this particular purpose, because it doesn't have the problem you're trying to avoid here in the first place.
romainl mentioned :help key-notation in the comments, but there's something to keep in mind here:
gVim not producing a keycode usually means there isn't one. <C-v> followed by numpad 9 in gVim produces <kPageUp>, but followed by numpad 5, it doesn't produce anything. Secondly, if you read :h key-notation, you'll see that it only defines home, end, up, and down, as well as the various operators, enter, and the decimal point. 2, 4, 6, and 8 are all registered as normal arrow keys, meaning <Down>, <Left>, <Right>, and <Up>. There's no way to detect these on the numpad specifically, but that's not really important.
If you've been keeping track, you'll find that numpad 5 is excluded. Note: When numlock is on, <C-v> + numpad 5 doesn't output anything in Vim or gVim, because the definition is:
Insert the next non-digit literally.
See :h i_CTRL-V.
TL;DR:
<C-v> is your friend.
Use:
nnoremap <Esc>OE <nop>
Or use <C-v> to insert the keycode, that may or may not be terminal dependent.
The mapping isn't necessary in gVim, and may not be possible.
The reason why you see this behavior is that Vim uses only the termcap interface of the terminal database. If it used terminfo, it would see a wider range of information.
Typing the key on the keyboard is misleading, because Vim (like almost all terminal applications) puts the keypad into application mode, which causes the terminal to send Escape and O rather than Escape and [ as a prefix. In terminal notation, that is \EO. In XTerm Control Sequences, that is referred to as SS3 (technically a misnomer since that applies to output, while keyboard input is input — but since no standards apply to keyboard input, that's good enough).
The terminal description for xterm at one point assigned \EOE to the kbeg capability (i.e., terminfo, which termcap names #1). That was a while back, around 1996.
Terminfo names are generally 3-5 characters, while termcap names are always 2.
Standard terminfo has a limited number of special keys (such as those for the numeric keypad which you are familiar with). All of the standard termcap names correspond to these terminfo names. In the standard arrangement, there are only five keys associated with a keypad: ka1, ka3, kb2, kc1, and kc3, which correspond to termcap's K1, K2, K3, K4, and K5. (Why there are no standard k2, kb1, kb3, or kc2 is long forgotten).
Looking for ways to improve the terminal descriptions in ncurses, a few different layouts of the standard keys have been proposed. But the best solution lies in adding new keys, using extended capabilities (a feature of ncurses since 1999). Those extensions all have names, and are chosen to conform to terminfo naming conventions. So... in May 2019, the terminfo building blocks xterm+keypad and vt220+keypad were introduced. In the former (used in xterm-new and xterm-256color, that key is named kp5.
There's no kp5 in the standard names listed in the terminfo(5) manpage. It is an extended (user-definable) key. In the older scheme some other key was unavailable for applications.
An ncurses application would automatically be able to use all of the keys, because ncurses uses terminfo (and adds all of the keys in a terminal description to its special cases for timing).
Vim will not see that key's definition because it views only a fraction (about a third) of the terminal description. Since it does not see the definition, it does not add that to the special cases where it will wait (a short time) for the completion of the character-sequence sent on that key. As noted in the other answer, in that case, Vim will see the commands Escape and O to insert the third character in the sequence, "E".
After attempting to use vim a number of times, I'm always been put off by its default key bindings. After some research, I decided to remap the default keys to more sane ones (at least for my tastes). I have a few questions about changing bindings that I could not find answers to through Google.
Is there a way to map a key to an action rather than another key. For example:
:noremap a h
will bind the a key to move the cursor left. Is there something along the lines of
:noremap a move-cursor-left
or
:noremap a :move-cursor-left<Enter>
so I can read my config file afterwards?
Is there a way to unbind all of the default key bindings? I've tried :mapclear but it doesn't seem to work, although it might just be clearing non-default bindings. Unmapping every key manually is not an option. If possible, I would like to export the defaults to a file so I can edit them as I need.
Is there another language I can use to write my own commands for vim other than vim-script? I haven't actually looked into this one so much though. If I can bind an external executable to a command, that would be good enough.
I haven't given up on vim although I would like to ask if there are any vim-like alternatives out there. My Google searches came up with nothing actively developed. If the above cannot be done, or reasonably hacked together, I would like to find a fully configurable, modal, command line text editor that can.
The command set of vi / Vim has 40 years of wisdom encoded into it; completely changing it is a bad idea. I can only repeat the reference to this answer from the comments; that should convince you (to accept this, or choose another editor).
Give the default commands another try. It'll take some time to get used to, but most Vim users swear by these. It's fine to make minor adjustments "for personal style": careful evolution, but not revolution. Also, some people with odd keyboard layouts (like Dvorak or Colemak) swap several keys for convenience.
The move-cursor-left is just h; aided by the excellent :help, you should be able to "read" your remappings just fine.
In general, even though it's possible to write extensions / plugins in integrated languages like Perl, Python, Ruby, etc. (based on support for them compiled into the Vim binary), you won't get around learning some key Vim internals and parts of Vimscript. If you don't feel comfortable at all about this, I'd suggest to use another editor. Unfortunately, with your requirements of full extensibility (and probably broad acceptance and platform support), there's only one serious alternative: Emacs (which cannot only be turned into everything but a kitchen sink, but also into a modal editor, too).
(i know this question is old)
you can reset the binds by just over-writing them
on vim you can use many <things> (idk the name)
e.g.
<Up> = Up-arrow-key
<C-f> = Ctrl, f
<A-Down> = Alt, Down-arrow-key
<Esc> = Escape-key
it's possible to remap the hjkl keys to wasd like this:
nmap w <Up>
nmap a <Left>
nmap s <Down>
nmap d <Right>
After attempting to use vim a number of times, I'm always been put off by its default key bindings. After some research, I decided to remap the default keys to more sane ones (at least for my tastes). I have a few questions about changing bindings that I could not find answers to through Google.
Is there a way to map a key to an action rather than another key. For example:
:noremap a h
will bind the a key to move the cursor left. Is there something along the lines of
:noremap a move-cursor-left
or
:noremap a :move-cursor-left<Enter>
so I can read my config file afterwards?
Is there a way to unbind all of the default key bindings? I've tried :mapclear but it doesn't seem to work, although it might just be clearing non-default bindings. Unmapping every key manually is not an option. If possible, I would like to export the defaults to a file so I can edit them as I need.
Is there another language I can use to write my own commands for vim other than vim-script? I haven't actually looked into this one so much though. If I can bind an external executable to a command, that would be good enough.
I haven't given up on vim although I would like to ask if there are any vim-like alternatives out there. My Google searches came up with nothing actively developed. If the above cannot be done, or reasonably hacked together, I would like to find a fully configurable, modal, command line text editor that can.
The command set of vi / Vim has 40 years of wisdom encoded into it; completely changing it is a bad idea. I can only repeat the reference to this answer from the comments; that should convince you (to accept this, or choose another editor).
Give the default commands another try. It'll take some time to get used to, but most Vim users swear by these. It's fine to make minor adjustments "for personal style": careful evolution, but not revolution. Also, some people with odd keyboard layouts (like Dvorak or Colemak) swap several keys for convenience.
The move-cursor-left is just h; aided by the excellent :help, you should be able to "read" your remappings just fine.
In general, even though it's possible to write extensions / plugins in integrated languages like Perl, Python, Ruby, etc. (based on support for them compiled into the Vim binary), you won't get around learning some key Vim internals and parts of Vimscript. If you don't feel comfortable at all about this, I'd suggest to use another editor. Unfortunately, with your requirements of full extensibility (and probably broad acceptance and platform support), there's only one serious alternative: Emacs (which cannot only be turned into everything but a kitchen sink, but also into a modal editor, too).
(i know this question is old)
you can reset the binds by just over-writing them
on vim you can use many <things> (idk the name)
e.g.
<Up> = Up-arrow-key
<C-f> = Ctrl, f
<A-Down> = Alt, Down-arrow-key
<Esc> = Escape-key
it's possible to remap the hjkl keys to wasd like this:
nmap w <Up>
nmap a <Left>
nmap s <Down>
nmap d <Right>
While vim's way of doing things is generally good, I feel like there are aspects that really get in the way as somebody who is not completely committed to vim for text-editing.
This means that I am hitting Esc+/ and typing slashes into files in Sublime Text, and hitting Ctrl+F in vim, scrolling down a page.
Similar things happen with Ctrl+S and :w and custom mapping ; to : still doesn't make it as convenient and fail-safe as Ctrl+S. Not to mention in PuTTY, Ctrl+S does something rather upsetting (it suspends output from the terminal till Ctrl+Q is pressed). Basically, IMHO some things (like switching to a "find mode" and saving the file) are good to attach to a global left-hand home-row shortcut chord rather than requiring the user to mess about in a modal command line. It simply is too often used to subject the user to these mode changes. I suppose this isnt a legitimate complaint because the entirety of vim is constructed around the modal concept, and these functionalities are a result of that.
In any case I'd like to make it a bit easier on my brain because I've tried for a while now to keep it all intact and it's simply too much (I have more or less internalized the switching between Ctrl on a windows machine on a desktop keyboard and the use of the thumb for the Cmd on my Macbook, but this modal text editor business seems to be too much). It did not take too much deliberation for me to decide that global homerow key chords are simply more intuitive.
Mapping Ctrl+S to :w is trivial, so the question here is about the find mode. I want to bind Ctrl+F to put me in find mode, but repeating it should not type slashes into the find command. Can this be done? Is there perhaps a colon-command that when executed simply drops me into the current find-command-buffer-thing?
In your .vimrc add:
inoremap <C-f> <Esc>/
noremap <C-f> <Esc>/
In whatever mode you are in, this will put you in "find" mode (it actually just types a slash in the command line which you can use to search). With these bindings it will work for all modes, even if you are in insert mode.
do you want this?
nnoremap <c-f> /
if you like you can also try
nnoremap <c-f> q/
the 2nd mapping brings you to a search history window. you could choose previous search keywords/patterns. also available to type new pattern (by pressing i)
btw, there is no find mode
Mappings can be defined separately for the different modes in Vim, see :help map-modes. This automatically takes care of your proposed <C-f> mapping: Initially, you're in normal mode, then the search pattern is entered in command-line mode.
If you so far only occasionally use Vim, and find it too "different", several things may make the switch easier:
easy Vim (evim or vim -y) defaults to insert mode
on Windows, :behave mswin and the $VIMRUNTIME/mswin.vim script create some common Windows shortcuts
graphical GVIM has menu items like Edit > Find... and toolbars.
Some things like the flow-control freeze on <C-s> in terminals are unfortunate, mostly historical accidents; you can't blame Vim for those.
You don't need to map anything. / is expressive enough and is definitely not slower than <C-f>. Same for <C-s> which, despite a certain familiarity, is not much better than :w<CR>. You are learning a new tool, remember?
What you should focus your efforts on is getting confortable with Vim's modality. The simple fact that, for you, doing a search involves hitting <Esc> is a sign that you didn't get that part. Your other comments on using Vim shortcuts in ST and ST shortcut in Vim are not good signs either and the part where you complain about having to adjust to your Mac's Cmd is the icing on the cake, IMO.
It may sound brutal but, from your question, it seems like you are doing too much at the same time, without organization and for, probably, no good reasons.
Switching from Windows to Mac OS X and switching from ST2 to Vim at the same time is sure to be confusing and I suggest you slow down a little and make a choice before you loose your mind and waste more of your time.
Which leads me to this: Why do you use a Mac and why are you using Vim?
Windows is a fine OS. Sublime is a fine editor. Even if you switch to the Mac, Sublime works very well there. So Why Vim?
If you are tired by some Sublime limitations and want the awesome power of Vim, fine. But you must wrap your head around its modality and awkwardness and accept to change your habit.
If you don't approach Vim with more flexibility, you'll never get full benefits.
If you decided to use Vim because it is trendy, I'll respectfully suggest you to stop there and go back to Sublime. Vim is weird, Vim is different, Vim is huge, Vim is a rabbit hole… if you are not ready to work with it and insist on not accepting its core design, you won't get far so why bother? You can pretty much live all your professional carreer without ever touching Vim. There's no shame in that.
Remapping / to <C-f>, on the other hand…
I'd like some map/remap/nmap/etc. commands to be case sensitive, e.g. "<C-I>" vs. "<C-i>".
I checked Google and :help map, but was unable to find this.
It appears you currently can't combine control with case-sensitivity in vim or gvim (I'm using 7.2). I might expect this to be a limitation of terminals for the former, but not the latter.
I tested it by typing this in a buffer:
map <c-i> :echo "c-i"<cr>
map <c-s-i> :echo "c-s-i"<cr>
Yank those lines, then :#" (when executes register " as commands). Verifying the maps with :map <c-i> and <c-s-i> shows the problem: <c-i> is <tab>, and only the last one takes effect, with the shift being ignored.
For alt, <a-i> and <a-s-i> do work as expected in gvim
In terminal vim, those two get mapped to é and É (at least here, check with ":map <a-i>" as above), and typing é/É directly (I use dead keys) does invoke the mapping. Actually doing a-i or a-s-i just enters insert mode.
Of course, non-control and non-alt maps work case-sensitively.
Add S for Shift
<C-S-i>
If you use your Caps Lock, (1) what on earth for?, and (2) you'll have problems. See here if this is your situation.
My bad.
Cannot be done, by design, with printable characters. The approach above does work with F1 et al, such as <C-S-F8>. See this thread for more.
My workaround would be to map it to something entirely different and obscure, and use AutoHotkey or similar to substitute the combination only for the uppercase variant.
Docs say that "CTRL-A and CTRL-a are equivalent".
Relevant part from :help notation
CTRL-{char} {char} typed as a control character; that is, typing {char}
while holding the CTRL key down. The case of {char} does not
matter; thus CTRL-A and CTRL-a are equivalent. But on some
terminals, using the SHIFT key will produce another code,
don't use it then.
(not intended as an answer, but as relevant info for anybody comming from search engine regarding case sensitivity)