I'm a long-time vim user trying to make the switch to emacs.
I'm using viper-mode in emacs and I keep typing ESC (to get out of insert mode) and then a key (say, j). I type fast and often hit them at the same time. Emacs then thinks I'm hitting META-j and runs a function which I do not intend.
I like using option as meta and don't care to have ESC ever be meta when I'm in viper.
Anyone have suggestions on how to completely disable ESC as meta in viper mode?
Here's a few related options that I've tried. None of these solve the issue.
(setq viper-no-multiple-ESC t)
(setq viper-translate-all-ESC-keysequences t)
(setq viper-fast-keyseq-timeout 0)
I was in the same boat, and this problem has been preventing me from trying emacs for quite a while. But I finally had some time to investigate, and think I've got a solution/workaround.
After looking at viper's source, I realised that contary to all the documentation I find, viper-translate-all-ESC-keysequences is a function. So setting a variable with the same name won't do anything.
So now I have (defun viper-translate-all-ESC-keysequences () nil) after my (require 'vimpulse) line in my .emacs file. And it seems I can spam my ESC key as much as I want now. Why the documentation was so misleading I don't know, but for now I at least get to try emacs with this workaround. Hope this helps!
The above answers didn't work for me. I looked up the viper documentation and found the two commands (viper-fast-keyseq-timeout) vs. (viper-ESC-keyseq-timeout). The former is to let Vi mode interpret any key combinations separated by the defined time to be Vi macro. The latter seems to be what we want, which is to ignore the special meaning of ESC in vi mode. Setting the latter to 0 solves the problem for me. (iterm2, mac os X lion)
[ref]
viper-ESC-keyseq-timeout 200 on tty, 0 on windowing display
Escape key sequences separated by this much delay (in milliseconds) are interpreted as command, ignoring the special meaning of ESC in VI. The default is suitable for most terminals. However, if your terminal is extremely slow, you might want to increase this slightly. You will know if your terminal is slow if the ESC key sequences emitted by the arrow keys are interpreted as separately typed characters (and thus the arrow keys won't work). Making this value too large will slow you down, so exercise restraint.
viper-fast-keyseq-timeout 200
Key sequences separated by this many milliseconds are treated as Vi-style keyboard macros. If the key sequence is defined as such a macro, it will be executed. Otherwise, it is processed as an ordinary sequence of typed keys.
Setting this variable too high may slow down your typing. Setting it too low may make it hard to type macros quickly enough.
viper-translate-all-ESC-keysequences t on tty, nil on windowing display
Normally, Viper lets Emacs translate only those ESC key sequences that are defined in the low-level key-translation-map or function-key-map, such as those emitted by the arrow and function keys. Other sequences, e.g., \e/, are treated as ESC command followed by a /. This is good for people who type fast and tend to hit other characters right after they hit ESC. Other people like Emacs to translate ESC sequences all the time. The default is to translate all sequences only when using a dumb terminal. This permits you to use ESC as a meta key in insert mode. For instance, hitting ESC x fast would have the effect of typing M-x. If your dumb terminal is not so dumb and understands the meta key, then you probably will be better off setting this variable to nil. Try and see which way suits you best.
This problem happened to me in console mode (i.e. when running emacs -nw).
Adding the following to my init.el seems to be the solution for me:
(set 'viper-fast-keyseq-timeout 0)
(set 'viper-no-multiple-ESC t)
(defun viper-translate-all-ESC-keysequences () t)
I also needed to add:
maptimeout 0
to my .screenrc file for running emacs inside of a GNU Screen session, or the problem would re-appear.
Also:
(defun viper-translate-all-ESC-keysequences () nil)
seemed to "work", but had the unintended effect of disabling M- style commands, so (for example) I couldn't use M-/ to run dabbrev-expand when in insert mode.
The (defun viper-translate-all-ESC-keysequences () nil) solution didn't work for me with terminal emacs running in iTerm2 -> ssh to Slackware 11 -> screen -> emacs 22.3.1
All I had to do was:
(custom-set-variables
'(viper-translate-all-ESC-keysequences t))
Note that the setting is "t", not "nil".
However, the solution for my OSX iTerm2 -> emacs 23.2.1, this was the fix:
(setq viper-fast-keyseq-timeout 0)
Related
I am a vi/vim person at heart but I use LaTeX a lot and I really like AUCTeX Preview so I have been using emacs with viper until recently, but I am now trying evil instead. I am however certainly no emacs expert.
Visual line mode in emacs is terrific with AUCTeX Preview because when the Preview images are activated, the line lengths are all mucked up, but if each paragraph is really only one long line, in visual line mode it all looks great whether the Preview images are activated or not.
One thing that has always annoyed me is that viper commands like 'j' and 'dd' only work on "logical lines", not screen lines. In vim one would instead use 'gj' instead of 'j', and indeed this is how evil works. However there is no equivalent for 'dd'.
I came across the answer to a SO question addressing this for vim and it seems to do the trick :nnoremap dd g0dg$. Indeed typing the "right-hand side" in evil (even with a numerical prefix) works exactly as it should.
However I cannot easily see in the evil documentation how one might achieve this remapping. I have seen a detailed answer to a general SO question about evil but all its suggestions and examples show how to map a key sequence to a single already-defined evil function. I can't see any examples where an existing evil key sequence is remapped to another (possibly longer) existing evil key sequence.
I guess I could replace the "right-hand side" of the mapping with a sequence of existing evil functions, but I'm not sure how one might do that. Or I could just use a basic emacs key remapping but I fear that this will interfere with evil's different modes/states, or simply just won't work.
Does anyone have any ideas?
Here's a basic function that does what I think you want (note that it doesn't do the other nice things like counts that Vim/Evil provide; use evil-define-command for that). You'll clobber some keybindings if you try to map it to gdd, so as a workaround, you could map it to gD (or whatever you like):
(defun evil-delete-visual-line ()
(interactive)
(let ((beg (progn (beginning-of-visual-line) (point)))
(end (progn (end-of-visual-line) (point))))
(evil-delete beg end)))
(define-key evil-normal-state-map "gD" 'evil-delete-visual-line)
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 noticed that iTerm2 offers the very convenient feature of using "Option key as +ESC" (or as meta, but apparently that's obsolete).
I tried them both and the option key works as expected in Bash (set -o emacs mode) and Emacs, but not in Vim. Thus, I can't make use of any "M-" bindings.
What I've found is that:
if I set option to "+ESC", vim just understands ESC+key, and has no idea I actually meant Meta-key.
if I set option to "meta", keys modified with "option" behave just as without a modifier (don't know how to formally test what vim understands from a key combination that I'm typing).
"M-" mappings work perfectly in MacVim (7.3.53), but that's outside of a console and not in the scope of this question.
I'm interested in how to make those mappings work in Vim, under iTerm2 or Terminal.
My specs:
MAC OS X Lion 10.7.2
iTerm2 1.0.0.20111020
vim #7.3.107_0+python26 [though MacPorts]
I've downloaded the latest iTerm2 and tried to see what it sent to/what was printed by Vim (i<C-v><M-a>) with the following settings:
Option as Option:
Vim prints æ which is normal and expected on my french keyboard
Option as Meta:
Vim stays there, waiting for something to happen. Nothing is printed. If I press Option and a in sequence I just obtain a. Pressing Option and a in some random order may print á, which is weird and totally unexpected.
Option as +ESC:
Vim prints ^[a which means "Escape character followed by the character a".
From these tests it appears that Vim will never ever receive <M-> without some hypothetical black magic.
If you stick with "Option as +ESC", it seems that you will have to change all your custom <M-something> mappings to <Esc>something. This may work but it will make writing any kind of prose in any non-english language a pain.
What I do: I leave the Option key as it is so that I can type characters like œ…«» easily and I use <Leader> (mapped to ,, see :help mapleader) for all my custom mappings.
Some people here like to reserve it for plugins and advocate a somewhat simpler and potentially safer approach.
inoremap <leader>, <C-x><C-o> "my way (copied elsewhere)
inoremap ,, <C-x><C-o> "another way
I left my option key to act as Normal and discovered that Vim saw them as <T- bindings. So, for example, I have this mapping setup in my .vimrc to move to the end of a word when in Insert mode:
noremap! <T-Right> <C-o><Right>;
I've been using Vim exclusively for a few weeks now, and a few things are keeping me from being very excited about my experience so far. For one, I am having trouble mapping a few key sequences to commands.
I'd like to map Ctrl+Shift+Z to :redo<CR> or alternately <C-R>, but apparently Vim is not able to recognize the difference between shifted and un-shifted control-key sequences:
Ctrl-b and Ctrl-B are synonymous, they both mean 0x02. This cannot be
changed, it goes back to ASCII, which dates back to 7-hole paper tape
(not counting parity).
This just seems silly to me. We've come a long way since 7-hole paper tape, and in my experience MANY programs recognize the difference between <C-S-Z> and <C-Z>. Indeed, MacVim even recognizes the difference! But no joy in GVim or in the GNOME Terminal. Is there a way around this? Maybe a plugin or even some compile-time option?
The other key combo that I'm having trouble with is Ctrl+, (control+comma). I'm not sure if I've got something configured wrong in my .vimrc, or if it's a real issue with Vim, but I cannot get <C-,> to respond after mapping it (for example: map <C-,> :TComment<CR>). FWIW, I have my leader key remapped to ;. Am I doing it wrong? Or is there some other reason why Vim won't recognize the <C-,> key combo?
I've spent way too much time googling and fiddling with key mappings, and I'm on the verge of declaring that Vim is not as flexible as I've been led to believe... I can't even get it configured with the key mappings I'm used to, some of which I am reluctant to re/unlearn since they work in other programs that I use daily.
It looks like the link you posted already answers your question regarding <C-b> vs. <C-B>. According to the FAQ it looks like you're out of luck with <C-,> as well, since this key combination is not in the list of Ctrl-printable-key chords that Vim can detect (possibly because it's not even a printable ASCII chord?).
Key combinations such as <C-S-w> are very un-Vim-like in that they undermine the efficiency of a modal editor. Of course there are times when <CTRL>-escaped combinations are necessary (for example in insert-mode mappings such as <C-x>-<C-o> for omnicompletion), but that's not the case for operations such as undo and redo.
I'm sorry that this reply won't satisfy you, but in the long run there is much to be gained from "doing it the Vim way", rather than trying to bend Vim to your will.
Try adding set nocompatable to your vimrc. without this you are basically running vi wich is much more limited than vim. This should allow you to map <C-S-r> or <F11> or whatever else you want.
Tjameson is completely right. it is much better to use the default mappings where they exist.
Let's see if I can explain myself.
I use vi-mode in bash, which is really great since I'm used to Vi.
When I'm inside vim and type : (to go to ex mode), since I'm used to the vi-mode from bash, I feel the slowliness of having to use this mode like the "regular" way of using bash.
Question is: is there a way of using vim's ex-mode like bash's (or readline) vi-mode?
Not sure if I understand what you're trying to do, but it might be something like hitting q: in normal mode?
For users that use Vim or vi bindings almost everywhere, including on their shell command line, it really hurts when you leave that environment. If you're used to the vi bindings hyperdrive, going back to chords for skipping words and other manoeuvres is painful and slow. Operating systems also differ on their default bindings so Mac, for instance, supports option-arrow instead of control-arrow, adding to the pain.
But there is one place where this also happens where it's really upsetting: in Vim itself. When working in Vim and entering command mode using : the default readline editing returns. Chords all over again. How to fix this?
Simple: When in "normal" mode, that is, when navigating around, type q:
Vim will drop you at the bottom of a full Vim full screen editing experience, go for your life
Additionally the command history is available on previous lines in the buffer
You can yank and paste lines and edit the commands as much as you wish
To execute a command in "command" or "ex" mode just hit ENTER on the line you want to execute
Hitting enter on an empty line closes the buffer and does nothing
But this is just another buffer so you can quit it as usual with :q as well
Although ESC leaves the "ex" command line, ESC in the buffer will not leave the buffer, because it's an actual buffer
The q prefix is used to introduce macro recording, so the q: variant is perfectly mnemonic for entering recording of an "ex" command line.
Note that q: to enter the buffer editing mode is very similar to :q ! You may have hit that by accident sometimes ;-) Now you know how to get out of it!
Zigdon had this answer a long time ago, of course, but it's pretty darn sparse, but then again, so is the question. If Zigdon adds this extra detail to his answer I'll be happy to delete this answer so that there can be one good answer.