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/
Additionally to start the search with ripgrep, start a vim search as
well. That way navigation between search results in the opened file is
easier.
The register is modified directly and hlsearch is turned on manually
instead of using the builtin `*`, so that the cursor does not move to
the next result in the current file.
Set `nomodified` after reading from standard input. This way the buffer
can be closed without error message.
This will **not** disable modified warnings completely. If the input is
modified after read, vim will reset `modified` (As it should).
Swap the behaviour of `[[` `[]`. This way the first bracket indicates
the direction of the motion and the second the target (i.e. open or
closed brace).
I assume that the reason behind these mappings is to be able to easily
change the direction of the move by 'inverting' the keys (e.g. `]]` ->
`[[`). I understand that, but find the new way more intuitive.
If a pattern is passed that starts with a special character, the
`[]`-"quoting" would possible lead to errors or change it's meaning.
To prevent that, pass the argument directly to grep if it looks like a
regex (i.e. contains a special character).
Instead of replacing pgrep, have this function under a slightly
different name.
Also add support for multiple arguments as the function does not aim to
be called under the same name now.
When an argument is passed that does not exist, `ls` always prints the
directory name for the existing ones, even if there is only one
remaining directory that is listed.
`ls` prints a warning if a non-flag argument is specified that does not
exist.
Previously ls-show-hidden assumed that all arguments that are neither a
directory nor an otherwise existing file are flags. As all flags are
passed to the ls call the warning still got printed, but this also lead
to the current working directory (i.e. `.`) being added to the
directories to process.
If `ls` expects an argument to a flag, it is always passed in the format
`--flag=arg` where the equal sign is mandatory. This makes it possible
to simply filter out all flags (and their arguments) from the other
arguments without needing to know which flags take an argument and which
don't.
Fix this behaviour by printing the same warning as `ls` does when an
argument is neither a flag, nor a directory nor an existing file. Also
only add `.` to the directories if *really* only flags were passed.
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.
