Functional keys (F1-F12) for vim in console don't work.
But the worst thing is when I hit such key, vim stays in some "mode" not allowing me to type anything for 2s... Very annoying
Another thing is after pressing Esc key vim pause for about 0.5s before go to normal mode.. But this is only happening in screen, even I set
export TERM=xterm
Anybody has some clean and short solution?
Sounds like some disagreement between the byte sequences vim thinks the terminal is going to send, and the sequences it actually does.
Also the half-second delay is a consequence of having some mappings that start with Escape.
Related
When I'm not in insert mode and I'm navigating around my file with the motion keys (hjkl etc), the keys often appear in the buffer (illustrated below). I can observe this effect pretty readily in tmux, but it doesn't seem to happen without. If I run :!reset in vim the buffer returns to normal, but it doesn't stay that way for long. I'm not sure why this is happening and google yielded nothing. Halp?
Edit: It seems just a simple :e will fix the problem, too.
I experience the same thing. A few extra observations:
it only seems to happen when I hold down a motion key like j or k, causing rapid repeats
it happens both in and outside of tmux, but much more often in tmux
it happens much more often since I enabled vim-go's go_auto_sameids, which I believe is making a call to an external program (guru) for every cursor movement
This leads me to assume that it's a timing issue in vim that is exacerbated by latency added by things like tmux and/or plugins.
(Using gnome terminal; $TERM is screen-256color in tmux and xterm-256color outside)
I think this was alluded to on the tmux mailing list recently. Try decreasing the value of the escape-time parameter in tmux, so that tmux more quickly sends the escape character to vim to return to command mode, rather than waiting for more characters in an escape sequence. The default value is 500ms, so try something smaller, like 50.
In .tmux.conf:
set-option -g escape-time 50
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'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)
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.
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.