Doc that vi-mode requires "set -o vi"

[stephenh]

In my .inputrc, I use "set editing-mode vi". Because this puts readline into vi-mode everywhere, I don't have a "set -o vi" in my .bashrc file, which AFAIK is for making "only bash" (and not other readline-using programs) use vi bindings.

Without "set -o vi", when .bashrc sourced .fzf.bash, the set -o | grep vi check returned empty, looking like vi mode was not setup, and so the non-vi key bindings where set.

However, after .bashrc was evaluated, my .inputrc settings took affect, and if I manually run "set -o | grep vi" in a terminal, then it does actually report as on.

Basically, AFAIK, .fzf.bash is running before .inputrc, so doesn't see the "set editing-mode vi" flag.

After struggling quite awhile with trying to figure out why Ctrl-T was doing bizarre things, I finally put "set -o vi" into my .bashrc, and now things work much better.

A hint in the docs might help future users avoid this confusion. I can add something to the readme if you like, unless it's terribly obvious that anyone using "set editing-mode vi" would of course also have "set -o vi" set. (Obviously it was not obvious to me.)

[junegunn]

Ah, you're perfectly right, thanks for raising the issue. I was a bit worried about this too, but I haven't found a solution yet. I particularly don't like the fact that even if you have set -o vi in your .bashrc, if it comes after source ~/.fzf.bash, the key bindings will not be correctly set. Mentioning this quirkiness in the documentation would be helpful of course, and we should probably do so, but it would be better if we could fix the problem. Do you know of a better way to handle this?

[junegunn]

I've just updated the key bindings section of the README page. But I'm still interested in a real solution :)

[stephenh]

Hi Junegunn,

Thanks for updating the readme...good call about the "set -o vi" being before the source also being a gotcha.

I don't have any good ideas for a real solution.

Perhaps fzf could wait until it was invoked to detect vi mode? I vaguely recall seeing some arcane binding setup on Stackoverflow where invoking one binding would, via a bash function, conditionally setup/"bind" the next binding, and then itself automatically invoke that next binding.

I think the con was that it "burned" a binding, in that you had to use two (or three?) bindings to accomplish it. Plus it was fairly complex anyway.

[junegunn]

Thanks for the reply. I googled a bit and I guess you're referring to this, right?
http://stackoverflow.com/questions/8366450/complex-keybinding-in-bash

I roughly tested the approach as follows:

__fzf_rebind() {
  if [ -z "$(set -o | grep '^vi.*on')" ]; then
    bind '"\C-x\C-t": " \C-u \C-a\C-k$(__fsel_tmux)\e\C-e\C-y\C-a\C-d\C-y\ey\C-h"'
  else
    bind '"\C-x\C-t": "\e$a \eddi$(__fsel_tmux)\C-x\C-e\e0P$xa"'
  fi
}
bind -x '"\C-x\C-f": __fzf_rebind'
bind '"\C-t": "\C-x\C-f\C-x\C-t'

So it re-binds C-x + C-t to the right version depending on the current setting. It functionally works but when the rebind function is executed via C-x + C-f as an intermediate step, I see a line feed. I don't know if it's possible to suppress this unwanted line feed, but if it's not, we can't employ this approach.

If you don't mind, I'll keep this issue open until we find a clean solution to the problem.

[stephenh]

Hi Junegunn,

Yes, that was the article...nice find! Sorry for not including the link, I was on my other machine.

That is odd about the new line; I don't have any good ideas. I'll try it out later when I have some time.

Until then I agree leaving the issue open sounds like a good idea.

Thanks for the great support on these issues; I only just came across fzf but I think I will quickly be very addicted to it. It's a great idea.