I act very rarely on the whole file but quite often on hunks, so it
makes sense to have the mappings for the latter shorter.
The new mappings I wanted to use for the whole file are conflicting with
`<leader>gf` (i.e. `:GFiles`), so I've disabled them for now.
Use git's preferred way of referencing commits (`--pretty=reference`)
instead of the kernel's (`--pretty='%h ("%s")'`). I can see that
specifying the date makes sense and that the quotes are at best
unnecessary in the parentheses and at worst confusing when the subject
contains quotes itself.
Link: https://git-scm.com/docs/SubmittingPatches#describe-changes
Commit 0369218114 ("vim:settings: Include `-` in `&iskeyword`") added
the dash to `&iskeyword` but I didn't give an explanation for the change
and don't remember what led me to it. Today I'm annoyed by it since it
breaks some stuff (e.g. previously the C pointer arrow and syntax
highlighting of negative numbers in Python). The C ftplugin is obsolete
now, so delete it.
This reverts commit 0369218114.
Instead of changing the functionality of `]]` and swapping `][` and
`]]` in one mapping, do it in two separate steps. This way both changes
can be used independently of each other.
Fixes: 459e0b7113 ("vim:keys:TODO: Modularize changes to ]]/][ maps")
When substituting in a visual block selection, the automatically
inserted range `'<,'>` is not enough as the pattern will also match
outside of the selection on the same lines. To only match inside the
selection, insert the `\%V` atom.
Theoretically the pattern will also need the atom before the last
character to make sure that everything is inside the selection, but this
can be inserted manually when needed (see `:h /\%V`).
These were commented out already for longer. For `(` I have delimitMate
and the `<CR>` mapping conflicts with the one from coc.nvim (which
includes the `<C-G>u`)
When switching to <Cmd> for mappings in fc9874bf97 ("vim:keys: Use
<Cmd> for plain command mappings") I forgot that the previously inserted
selection range marks (i.e. '<,'>) are missing now. This broke vmaps
that used :substitute without having added them manually.
Since <Cmd> has some performance benefits, I want to keep it and add the
missing marks where needed.
Use tmux popup windows for fzf in vim, so that it spans (almost) the
full tmux window. My use-case for this is, that sometimes I open fzf in
a split pane and notice then that the lines are too long for the width
of the pane. Since the fzf window won't resize if I resize the pane
(TODO: issue in fzf.vim), I have to first close it, resize and then
reopen fzf. I hope to fix this by using always the big tmux popup and
eliminating the need to resize at all. The issue remains when vim is in
a split window outside of tmux. I can imagine that this will become
annoying, but we'll see...
I sometimes work in files where I cannot remove trailing whitespaces (at
least not permanently). In these cases the background highlighting of
them is quite strong and can be a bit annoying. To make this more
pleasing, use the foreground to highlight trailing characters, as long
as tabs and trailing spaces are displayed as non-space characters.
For this I also set `trail` in `&listchars`, and while at it, merged the
two lines setting `&listchars` and cleaned up some comments.
Use the `s` flag, so that the position before the last jump is updated
automatically.
Use `<Cmd>` so that both normal and visual mode mappings become
identical and can be merged. This has the added benefit that it now also
maps in operator-pending mode.
Complete the TODOs.
Apparently on older neovim versions, passing the name of script-local
functions to `timer_start` is not enough (in v0.10.2 this works, but
v0.7.2 not). Fix this by wrapping it in `function(...)` to pass a
Funcref.
See :h timer_start:
> timer_start({time}, {callback} [, {options}])
> [...]
> {callback} is the function to call. It can be the name of a function
> or a |Funcref|. [...]
Because of the deferring of the highlight, the old selection highlight
was deleted only when a new one was created. Introduce a second timer
that makes sure that the old highlight is cleared earlier.
Sometimes `_highlight_cword` is called without the existence of
w:cword_timer_id but with a w:cword_match_id. No idea why.
I thought that it might be a race condition, but does not seem like it.
(Also not sure if this could even run in parallel)
TODO: Investigate how _highlight_cword can be called without
w:cword_timer_id
Defer the clearing of the old highlight as well. This means that the old
highlight will remain a bit longer but prevents the highlight from
flickering because of the continuous `matchdelete`.
`highlight_selection()` is supposed to abort if the visual mode was
started on an empty line. This was done correctly for charwise-visual
but failed to do so in linewise-visual.
- Combine one `exists` call with an implicit `get` into a `get` with an
empty default
- Do not stop any timer in the `Highlight*` functions as this done
already by `ClearHighlights`
- Get rid of the check for existence of `w:*_timer_id` since I believe
that there is no way of it being unset in the current state. The
`_Highlight*` functions are only called via the timer so there should
always be the variable. I could also not reproduce the description in
the comment - this might have been true in a previous revision.
- Make sure that the visual selection itself is not matched. This
actually increased the performance a lot while also looking like
normally (there were some subtle differences between the highlight by
visual mode and `CursorColumn`)
The default setting of `g:loaded_nrrw_rgn` is `topleft` which opens the
split at the very top/far left and makes the window have full
width/height. This is very annoying when narrowing multiple splits.
I assumed that the selection will always be one character long when the
ModeChanged event is triggered. This is not the case when entering
linewise visual mode.
Fixes: b0688da69e ("vim:aucmd: Do not highlight selection on
ModeChanged")
TODO: There are more ways of triggering ModeChanged to visual mode with
a selection of more than one character (e.g. `[count]v`).
This makes it a lot easier to restrict the search (besides searching in
visual selection, which is quite limited). The cursor will still land on
the closed fold but only once, independent of the number of hits inside
of the fold.
There are operations that change the visual selection without moving the
cursor (e.g. `viw` when on the last character). These do not trigger
CursorMoved so the highlighting also does not change.
TODO: <COMMIT>
Do not call HighlightVisualSel when the mode changes to visual mode, as
then the selection is still only one character long, which I rarely want
to highlight. If I do I can still move the cursor forth and back once.
TODO: Are there situation where ModeChanged is triggered and the
selection is immediately longer than one char without triggering
CursorMoved?
