-
-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Doc that vi-mode requires "set -o vi" #39
Comments
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 |
I've just updated the key bindings section of the README page. But I'm still interested in a real solution :) |
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. |
Thanks for the reply. I googled a bit and I guess you're referring to this, right? 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 If you don't mind, I'll keep this issue open until we find a clean solution to the problem. |
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. |
Introducing bash vi-mode in ce0f35a caused problems in fzf key bindings. The solution is to source `set -o vi` above fzf.sh. To achieve this, the bash_exports and bash_options file have been moved to the top in bash_profile. junegunn/fzf#39
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.)
The text was updated successfully, but these errors were encountered: