This commit addresses a couple of issues:
1. fzf's `key-bindings.zsh` was sourced twice: Once in keys.zsh and once
via the symlink in `external-plugins/`. Fix this by removing the
source in `keys.zsh`.
2. The section about the fzf bindings in keys.zsh was a mess. Reorder
and rewrite some comments to make it nicer.
3. My just added custom `fzf-cd-inplace-widget` does not work like this.
Since `key-bindings.zsh` is sourced (was sourced again) after
`keys.zsh`, my override is overridden itself by the default. I
noticed and fixed this when I originally wrote and tested the
function, but unfortunately I forgot the old `bindkey` commands in
`keys.zsh`, which is why I now forgot about it and committed this
erroneously. To fix this, bind the keys after sourcing
`key-binding.zsh` in the newly added `fzf.key-bindings.config.zsh`.
Additionally, move the widget definition as well to have everything
at one place.
Fixes: 3cf445e739 (zsh:keys: Modify fzf's cd widget to be "in-prompt",
2025-08-06)
Currently, fzf's cd widget executes the cd command via accept-line, so
the command is also visible in the scrollback buffer. In contrast to
this, the cd-{forward,backward,up} suite changes the directory in-place,
without touching BUFFER, with an additional prompt redraw (one could say
"in-prompt"). Since I find this more appealing, overwrite the default
fzf widget with a custom one that has the same behaviour.
I forgot that this was already a thing before d961daf38 ("zsh:keys:
Change one dir up on `^U`") and missed that I only moved the function in
the file instead of creating it (the changes were lying around a bit).
vi-kill-word does not exist. This change was lying around uncommitted
for ages now.
Fixes: 658797bda2 ("zsh:keys: Use `vi-` variants of navigation binds")
This way better solution using the `(A)` flag was given to me in the
zsh-users mailing list back in 2022 but I forgot to apply it.
See zshexpn(1):
> Convert the substitution into an array expression, even if it
> otherwise would be scalar.
Thanks Mikael!
Link: https://www.zsh.org/mla/users/2022/msg00668.html
I never really noticed but `$FZF_ALT_C_COMMAND` was never set as
`$fzf_default_no_rg` would be empty. Because the variable was not
exported, the X session would not have it in it's environment.
When typing a multi-line input (e.g. `echo foo\<CR>`) BUFFER can be
empty, even though the entire input is not.
Fix this by checking if PREBUFFER and BUFFER are empty.
The `vi-` versions stop working after using `push-input` and trying to
edit the reappeared line.
This could be an upstream bug, as I can recreate it with `zsh -f`.
Introduce first mapping that follows the 'fixed keyboard input'[^1]
sequences. They allow the differentiation of all keys with each modifier
without gotchas like `tab` send the same sequence as `ctrl-i`.
[^1] - https://www.leonerd.org.uk/hacks/fixterms/
Previously the path preview misbehaved when typing dots on the first
shell word (e.g. executing a script in a parent directory). This
happened as the `(z)` parameter expansion flag does not expand to an
array rather a scalar. Because of that, `[-1]` returns the last
character.
Work around this issue by prepending LBUFFER with a dummy word, so that
it always contains at least 2 words.
Handle an LBUFFER value of `..` before pressing `.` by adding `/../`.
This scenario can only occur by deleting previously added segments or
using the new `default_dot` (See previous commit 72a8cfbcb ("zsh:keys:
Add normal `.` behaviour on `Ctrl-.`")).
Having bound `.` to `rationalize_dots` makes typing paths with multiple
`../` segments super easy. This gets cumbersome in some situations
though.
Typing a path like `../.local` is only possible by either typing
`../.<BS><BS>local` (as it is expanded to `../../` on the third dot) or
`..//.local` which is not as annoying but somehow breaks completion on
further path segments.
Bind `Ctrl-.` (i.e. `^N`) to insert a normal dot.
Move the fallback for $FZF_DEFAULT_COMMAND into the variable
fzf_default_no_rg that is always set.
This way FZF_ALT_C_COMMAND can reuse it instead of spawning a new shell
and messing with PATH.
For deleting a word while in the shell, I find it easier/faster to use
emacs bindings or Ctrl-Backspace and backward-kill-word instead of the
vi version.
In tmux, Ctrl-H (same esacape sequnce as Ctrl-Backspace) is used for
switching panes since f11b7fa56545 ("vim,tmux:plugs: Add
`vim-tmux-navigator`"), so I need to use Ctrl-W.
As that is bound to vi-backword-kill-word, rebind it to use the emacs
version.
Refactor the function to keep an array of commands with requirements
that have to be met. Those commands are then cycled over a wrap around
index instead of the inflexible switch statement.
Go back to a simpler approach, that the `fzf-history-widget` is only
called on <C-Up> and ^K in normal mode and <Up> & <Down> scroll through
the history normally.
The reason behind this change is that there were still some edge cases
in which the widget was wrongfully called when normal scrolling was
intended.
This change also makes it now possible that I can use commands in the
'surrounding' of a past command by first navigating to it with the
fzf-widget and then just using <Up> & <Down>.
If a command is normally executed CMD_ON_ENTER is reseted to `ls`.
Otherwise problems can occur when for example switching the directory to
a non-repo when CMD_ON_ENTER contains `gs`.
