From :h :Man:
> when running `man` from the shell and with that `MANPAGER` [='nvim
> +Man!'] in your environment, `man` will pre-format the manpage using
> `groff`. Thus, Nvim will inevitably display the manual page as it was
> passed to it from stdin. One of the caveats of this is that the width
> will _always_ be hard-wrapped
Since I actually don't like `g:man_hardwrap=0`/`MANPAGER=999` (e.g.
scrolling can be a mess with very long wrapped lines), add an
autocommand that is meant to reload the manpage through `:edit` after
every resize, so that its hard-wrapping adjusts to the new size.
This is slightly hacky, but does its job quite well.
Move the man.vim into after/ftplugin so that it overwrites the `set
wrap` of the global ftplugin, which I want turned off, since it messes
with the buffer shortly when resizing.
man(1) will assume it can use the full width of the terminal when
hard-wrapping the lines. When signcolumn is enabled the width is one
cell smaller and thus, lines that have a character in the last column
will be wrapped by vim (i.e. almost all of them).
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?
Setting `&spellfile` from the modeline is not allowed and will result in
an `E523: not allowed here` error. Fix the updating of the file by
additionally having an autocommand on BufWinEnter (i.e. after the
modeline was read).
TODO: Also get rid of the error message when rereading the modeline (:e)
