I would like to have a mapping to quickly quit all buffers, for use when I'm vimdiffing a lot of files. Control and a function key together proved a good safety, so that I don't accidentally hit this combination, unintentionally leaving Vim. I tried the following mapping:
map <C-F10> :qa<CR>
To no avail. If I ditch the control, I can quit with F10 alone—why doesn't control work with F10 in my mapping?
I suspect you are using vim and not gvim. vim keybindings are limited by the terminal we are running vim within.
I've given up on vim, and I systematically use gvim for that reason.
Luc is right - I just tried that in gvim (well, MacVim) and it worked fine. Then I tried it in the terminal with no joy.
Related
Using all of Vim, Xvim(for Xcode) and Ideavim(for IntelliJ), I'd like to be able to use the default keybindings while in insert mode rather than Vims. I've been using Xcode for quite some time now and have gotten quite good at typing with the standard Xcode bindings but Vim bindings are so much better while not in insert mode.
I know you can do .vimrc settings such as
:im <C-D> <esc>xa
to emulate these functions, but this still leaves problems with slightly different behaviors as well as losing functionality where these commands have multiple uses. IE ctrl+n is both down while typing and next while scrolling through autocompletions. Custom bindings in .vimrc removes the ability to scroll through autocompletions.
Using
:im <C-N> <NOP>
enables scrolling through autocompletions but still doesn't let it function as down.
Anybody know how to solve this?
If you really want to, you can put
nnoremap i :action VimPluginToggle<CR>
into your ~/.ideavimrc, then in Preferences => Keymap, find the Vim Emulator item and assign the shortcut ESC to it. This when instead of entering insert mode, you'll be disabling IdeaVim, and hitting ESC will re-enable it.
I tested this briefly and it does seem to work at least at a superficial level, although you lose the changing caret style as an indicator of which mode you're in. I'm not sure that's a good idea, however. Probably better to work within the system as designed and set up the bindings you want.
Evening,
I got a Lenovo T400 laptop, and the F1 is in a stupid place, and keep hitting it instead of hitting Esc to get change modes with VIM.
I did some googling, and tried adding
map <F1> <Esc>
imap <F1> <Esc>
to my ~/.vimrc file, but to no avail...
If I can't do this with a vimrc, is there a way to change it at the linux/system level?
Using Linux Mint 14 MATE
--
Answer:
The terminal application has it's on keyboard shortcuts defined. Under Edit -> Keyboard Shortcuts you can disable the help. Then the map/imap above will work fine.
You can also edit the keyboard settings in the main system keyboard preferences. Open that up and go to Layouts -> Options and play with the Caps Lock key behaviour. You can disable it, or even bind it to ESC.
It may be that your keyboard isn't producing the keycode that Vim translates to <F1>. In Vim, go into insert mode, and type Ctrl-v. Then press F1. The string that you just inserted is the string that needs to go on the left-hand side of your map command. It might be <x-F1> or something similar. You can do this to insert the key name directly in your .vimrc file.
Remember to restart Vim after editing your .vimrc file.
Regardless of whether you get this working, you might like to swap your Esc and Caps Lock keys, which is quite a popular thing to do among Vim users. You can't do that within Vim, you need to edit your X configuration to achieve it. The Vim tips wiki tells you how.
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 have been trying to map ctrl s to save during insert mode in vim. It never seem to work
http://vim.wikia.com/wiki/Map_Ctrl-S_to_save_current_or_new_files (and many other tutorials) does not seem to work
I am using iterm, vim 7, and I have .vimrc file under my current user. I have reloaded my .vimrc with :source $MYVIMRC
Did I do something wrong?
Same thing with mapping any other key. mapping just does not seem to work.
Many keys cannot be intercepted on terminal, because they are interpreted by the terminal and not passed to vim at all. Ctrl-S is one of those keys, meaning "suspend" to most terminals. Either use the GUI version of vim, or select key combinations that work on your terminal.
I'm running Vim on a gnome terminal. But the alt key mappings are not working. For example:
:imap <A-i> <Esc>
It works fine in GVim. But when I run the same command with Vim in the gnome terminal it does nothing.
I'm using Windows 7, The problem is with the terminal, right?
The problem
There are two ways for a terminal emulator to send an Alt key (usually called a Meta key as actual terminals didn't have Alt). It can either send 8 bit characters and set the high bit when Alt is used, or it can use escape sequences, sending Alt-a as <Esc>a. Vim expects to see the 8 bit encoding rather than the escape sequence.
Some terminal emulators such as xterm can be set to use either mode, but Gnome terminal doesn't offer any such setting. To be honest in these days of Unicode editing, the 8-bit encoding is not such a good idea anyway. But escape sequences are not problem free either; they offer no way of distinguishing between <Esc>j meaning Alt-j vs pressing Esc followed by j.
In earlier terminal use, typing Escj was another way to send a Meta on a keyboard without a Meta key, but this doesn't fit well with vi's use of Esc to leave insert mode.
The solution
It is possible to work around this by configuring vim to map the escape sequences to their Alt combinations.
Add this to your .vimrc:
let c='a'
while c <= 'z'
exec "set <A-".c.">=\e".c
exec "imap \e".c." <A-".c.">"
let c = nr2char(1+char2nr(c))
endw
set timeout ttimeoutlen=50
Alt-letter will now be recognised by vi in a terminal as well as by gvim. The timeout settings are used to work around the ambiguity with escape sequences. Esc and j sent within 50ms will be mapped to <A-j>, greater than 50ms will count as separate keys. That should be enough time to distinguish between Meta encoding and hitting two keys.
If you don't like having timout set, which times out for other mapped key sequences (after a second by default), then you can use ttimeout instead. ttimeout applies only to key codes and not other mappings.
set ttimeout ttimeoutlen=50
For Gnome-terminal, use the following instead:
imap ^[i <Esc>
^[i should be typed by pressing Ctrl-v Alt-i
Attention: You need to yank and put in Vim when you want to copy it elsewhere. If you just copy the mapping in an editor like gedit, the mapping will probably be broken.
EDIT here is an example which makes Alt-k add an empty line above the cursor, and Alt-j add an empty line after the current line.
" Alt-j/k to add a blank line
if has('gui_running')
" the following two lines do not work in vim, but work in Gvim
nnoremap <silent><A-j> :set paste<CR>m`o<Esc>``:set nopaste<CR>
nnoremap <silent><A-k> :set paste<CR>m`O<Esc>``:set nopaste<CR>
else
" these two work in vim
" shrtcut with alt key: press Ctrl-v then Alt-k
" ATTENTION: the following two lines should not be
" edited under other editors like gedit. ^[k and ^[j will be broken!
nnoremap ^[k :set paste<CR>m`O<Esc>``:set nopaste<CR>
nnoremap ^[j :set paste<CR>m`o<Esc>``:set nopaste<CR>
endif
Try
<m-i>
Or, if typing alti inserts a character (like in my case, it inserts a carret: ˆ) just map to that character:
:inoremap ˆ <esc>
Be careful, because this one wouldn't work (at least in my system, MacOS 10.6). The caret waits for a letter, because it's not exactly a caret, it is a circumflex.
It may be that the shortcuts are actually from the Gnome Desktop. Try looking at the Gnome Keyboard Shortcuts tool (System menu, Preferences, Keyboard Shortcuts), which lets you view and modify the shortcuts defined on Gnome Desktop. If the key combination is assigned to a function on Gnome Desktop, then remove it and then that key combo should filter down to Vim properly.
Or you may be right that it is a problem of the terminal. Not all terminals support all key combos. Your problem may be the one described in the Vim help docs at :h map-alt-keys. The docs provide a workaround, but not a very good one.
The same thing happens to me. I searched on Google with "gnome terminal alt key", and found that someone asked almost the same question: "How to disable the alt-hotkey behavior on gnome terminal?" in the first link found. (The second link is just this question)
So, maybe you can try that:
Edit > Keyboard Shortcuts, and uncheck "Enable menu access keys"
Take a look at section 1.10 of http://vimdoc.sourceforge.net/htmldoc/map.html. It seems to indicate that gnome-terminal automatically escapes the Alt modifier, so that it doesn't switch the byte sent in the way that Vim is expecting. The document seems to indicate that there isn't really a way around this except for using a different terminal (such as xterm).
This is certainly frustrating because so far as I can tell Linux machines are also incapable of using the D (Mac's Command or Linux's Super) bindings, so at least as far as the terminal goes, we are limited to Shift and Ctrl modifiers, which is frustrating if we want to ensure that we can use all the commands we use in Gvim on terminal Vim (at least without switching terminals, towards which I'm perhaps overly stubborn - gnome-terminal is just so much prettier). I've been looking for a way around this but have been unable to find anything.