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`.
The file should be opened if fzf returned something not the other way
around. This probably happened in the last refactoring session before
committing.
Move every file from plugins into zshrc.d as well as all bigger blobs in
the zshrc into their own files there.
Some stuff is still in there that I am not all too sure where it
belongs. TODO: Move.
Because all external plugins are now sourced over a symlink I had to
create a fork of fzf-tab for now that supports that.
See: https://github.com/Aloxaf/fzf-tab/pull/153
