`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?
The cursor is always moved to the beginning of the selection when
yanking in visual mode. This mapping resets the position back to where
it was.
Link: https://stackoverflow.com/a/3806664/20927629
If :h 'spelllang' is something else, do nothing.
A possible future improvement could be to keep a list of the languages
to cycle between and first adding any other languages to this list so
that one could return to the original setting. I see this especially
useful when the current setting is `en,de`.
Make ][ and ]] work like they used to with the new functionality through
a workaround.
The problem is that recursive mappings are evaluated at runtime not
"compiletime" - which is what I would need in this situation.
I still want both mappings blocks so that they are not entangled and I
can turn each one off without affecting the other.
I use the [[ & etc. mappings to jump between function definitions in C.
This works as long as the braces are put on a newline (like in the
kernel coding style guide).
Relax the mappings for opening braces to jump to unindented lines with
an opening brace to cover also different style guides.
When entering visual mode it does not really make sense to keep the
cword highlighting but it should restart automatically (i.e. without
CursorMoved) when leaving back out of visual mode.
About directly starting selection highlighting I am still unsure since I
rarely ever want to highlight only one character and it could decrease
performance.
When exiting visual mode I want to clear the highlights of the visual
selection. As this is done automatically now, <Esc> does not need to do
it (and i had problems with keys.vim executing ClearHighlights because
of the script variables).
This reverts commit b3f1a469db ("vim:keys: Clear highlights on
normal-mode Esc").
The mapping to split and open the file under cursor exists by default
(not as I thought), but is not <C-w>gf but rather <C-w>f.
Swap the mappings for tab and split 'destination'.
Fixes: 8096917ad ("vim:keys: Open file in split with `<C-w>g[fF]`")
