Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I am really liking the general speed of zsh, but two things are annoying the heck out of me.

  1. I have to hit wait a moment between hitting escape and hitting slash to get to the history search (if it hit slash too quickly it says zsh: do you wish to see all 514 possibilities (172 lines))
  2. After entering insert mode because of hitting a or A, I can't backspace past the point where I entered insert mode.

I know that 2 is like classic vi, but I like the vim style better.

share|improve this question

2 Answers 2

up vote 11 down vote accepted

(1). For some reason, bindkey behaves oddly when it comes to "/": <esc> followed quickly by / is interpreted as <esc-/>. (I observed this behavior the other day; not quite sure what causes it.) I don't know if this is a bug or a feature, and if it's a feature if it can be disabled, but you can work around it fairly easily.

This key combo is probably bound to _history-complete-older, which is generating the undesired result – you can use bindkey -L to see the if this is the case.

At any rate, if you don't mind sacrificing the actual <esc-/> (pressed together, as a chord) binding, you can re-bind it to the vi-mode history search command, so that typing <esc> followed by / does the same thing at any typing speed. =)

Since this will be treated as a chord, it won't have the effect of first entering vi command mode, so we'll have to make sure that happens first. First, you need to define a function; put it somewhere in your fpath if you use that, or put it in your .zshrc otherwise:

vi-search-fix() {
zle vi-cmd-mode
zle .vi-history-search-backward
}

The rest goes in your .zshrc either way:

autoload vi-search-fix
zle -N vi-search-fix
bindkey -M viins '\e/' vi-search-fix

Should be good to go.

(2). You can fix the backspace key as follows:

`bindkey "^?" backward-delete-char`

Also, if you want similar behavior for other vi style commands:

bindkey "^W" backward-kill-word 
bindkey "^H" backward-delete-char      # Control-h also deletes the previous char
bindkey "^U" backward-kill-line            
share|improve this answer
    
It was under ^[/ not \e/, but those are both valid ways of saying escape. The change works perfectly. Now that I am playing with it more completely, it looks like zsh's vi mode sucks in comparison to bash's (or at least is not fully configured by default). One example of this is the fact that it drops you into insert mode after the searching history. I have to go back to command mode to hit n to find the next search item. –  Chas. Owens Jan 14 '13 at 12:36
1  
Well, I don't know if you have any other examples, but the one you mention is my fault, not zsh's. =) What's happened is I've bound a vi-cmd mode editor command in vi insert mode – the command expects the shell to already by in cmd mode and behaves accordingly. We need to write an editor command which first calls the "enter cmd mode" command, and then executes .vi-history-search-backward. I'll write it and edit my answer – check back later today. –  marshaul Jan 14 '13 at 13:14
    
OK, I updated my answer. Try it out. –  marshaul Jan 15 '13 at 0:26
    
With regards to (2), when I do bindkey | grep <searchterm> for any of the terms, they're all prefixed by vi-. Do I need to set up bindkey commands that aren't prefixed by vi-? –  adam_0 Feb 13 '13 at 18:05
    
adam_0, I'm not quite sure I understand the question. Perhaps you could elaborate on what you're trying to do, and how what you're seeing differs from what you expect. –  marshaul Feb 14 '13 at 13:38

I'm only going to address question (1).

Your problem is KEYTIMEOUT. I quote from zshzle(1):

When ZLE is reading a command from the terminal, it may read a sequence that is bound to some command and is also a prefix of a longer bound string. In this case ZLE will wait a certain time to see if more characters are typed, and if not (or they don't match any longer string) it will execute the binding. This timeout is defined by the KEYTIMEOUT parameter; its default is 0.4 sec. There is no timeout if the prefix string is not itself bound to a command.

That 0.4s is the delay you're experiencing after hitting ESC. The fix is to set KEYTIMEOUT right down to 0.01s in one of the shell startup files:

export KEYTIMEOUT=1

Unfortunately this has a knock-on effect: Other things start going wrong…

Firstly, there is now a problem in vi command mode: Typing ESC causes the cursor to hang, and then whichever character you type next gets swallowed. This is because ESC is not bound to anything by default in vi command mode, yet there are multi-character widgets that start with ESC (cursor keys!). So when you hit ESC, ZLE waits for the next character… and then consumes it.

The fix is to bind ESC to something in command mode, thus ensuring that the something gets passed to ZLE after $KEYTIMEOUT centiseconds. Now we can keep bindings starting with ESC in command mode without these ill effects. I bind ESC to the bell character, which I find to be even less intrusive than self-insert (and my shell is silenced):

bindkey -sM vicmd '^[' '^G'

Next problem: There are by default some two-key widgets starting in ^X in vi insert mode; these become unusable if $KEYTIMEOUT is set all the way down. What I do is unbind ^X in vi insert mode (it's self-insert by default); this allows those two-key widgets to continue working.

bindkey -rM viins '^X'

You lose the binding for self-insert, but you can bind it to something else of course. (I don't, since I have no use for it.)

The last problem (I've found so far): There are some remaining default keybindings that we "lose" due to setting $KEYTIMEOUT right down, to wit: those starting with ESC in vi insert mode which are not cursor keys. I personally rebind them to start with ^X instead:

bindkey -M viins '^X,' _history-complete-newer \
                 '^X/' _history-complete-older \
                 '^X`' _bash_complete-word
share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.