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`)
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`).
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?
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").
Underline old cursor position for better readability. Reusing
`TermCursor` made me confuse the current window many times.
My favorite solution would be an empty box around the position similar
to how terminals do it when focus is lost. But I fear that this is not
possible with a simple highlighting group.
When deleting the match, w:old_cword has to be unset as well. Otherwise
it can happen that it is not properly readded (e.g. when moving from a
word to an empty line and then back to the same word).
When highlighting the current word, check if it is the same as the
currently highlighted one, so that matchdelete and matchadd are not
called unnecessarily.
Use `matchadd` instead of `match` as it has no limit on the number of
highlights.
Also call the function every time the cursor moved instead of only when
holding. This makes it snappier while also keeping the highlight when
moving inside the cword.
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).
Check that the current word under the cursor exists (not empty) before
adding it as match.
Fix the disappearing of the welcome screen after a short time when
opening vim without file as argument.
Step by step I want to restructure the vim files. The approach to
cleanly divide the config by topics works in zsh pretty well, but is too
vague in vim for my liking.
Especially (the very small) functions and autocommands that have the
purpose of setting options or mapping keys or the interplay of multiple
categories together, make it difficult to decide in which file the
snippets should lay.
Apply the following:
1. Switch to `matchadd` as `match` can only be used for **one**
highlight
2. Use an autocommand group for better behaviour when reloading the
vimrc.
3. Use just one pattern as it seems to work always. (Apparently `\%#` is
not matched in normal mode)
As relative line numbers are only really needed in normal mode and in
the current buffer, disable them in insert mode or when the
buffer/window is not focused.
The old `textwidth` value is meant to be subtracted from colorcolumn, to
then add the new one.
Fixes: 41656d28d6 ("vim:autocmd: Reset textwidth value in colorcolumn")
