Allow highlighting the entire line while in Visual Line Mode

[ColinKennedy]

Is your feature request about something that is currently impossible or hard to do? Please describe the problem.
This is a split issue from #14170. in VISUAL LINE mode, Vim highlights every non-whitespace character. This helps differentiate VISUAL LINE/V-LINE from the other visual modes but since this mode also captures the ending newlines, I think it'd help if this mode communicated "I capture the full line, not just the leading whitespace and non-whitespace characters" more clearly compared to the other visual modes which do not capture the full line.

Describe the solution you'd like
Basically implement a new option to enable full-line highlighting, like how this plugin does it - https://github.com/0xAdk/full_visual_line.nvim

Or maybe people would be comfortable for this becoming the new default behavior. At the moment I'd be more than happy if this screen behavior was a simple opt-in global setting.

Describe alternatives you've considered
Continuing to use https://github.com/0xAdk/full_visual_line.nvim. It's a good plugin but sometimes has flickering + latency issues in Neovim while working in larger files due to how it needs to run last in Neovim's event loop to ensure accurate results. If this feature lived in the (Neo)vim core then it would work as expected.

[laburnumT]

For me it does add the extra space at the end which indicates it took
the newline. Though I guess that is slightly different from what you're
proposing.

[chdiza]

This should absolutely not be default behavior, and I'm not even seeing why it should be added at all (especially if there's a plugin). Visual mode should show what's been selected, and not (except for special cases like virtualedit) falsely claim to have selected stuff that doesn't exist in the buffer.

The picture of the allegedly desired behavior is "claiming", pictorially, that there's quite a bit of trailing whitespace hanging on every line in the range.

[ColinKennedy]

For me it does add the extra space at the end which indicates it took the newline.

Interesting. I was able to reproduce this with vim -u NONE (Vim 8.2) but not with nvim -u NONE (Neovim 0.10 nightly). In Neovim VISUAL and VISUAL LINE select the same character ranges, it seems (Edit: Apparently nvim requires also setting listchars=eol:$ since it's off by default). That said though, the selection image you've posted could be VISUAL LINE or VISUAL mode, if the line(s) have a trailing whitespace character.

The selection range by itself doesn't communicate "this is a visual line selection and that last character is actually a newline" unless your user also :set list and set listchars=eol:$ to show the newline so it's included as part of the selection. Neovim doesn't even set listchars eol by default. Apart from list&listchars, the only way to know for sure the difference would be to look down at the status line and see if it reads VISUAL or VISUAL LINE.

(Neo)Vim could communicate the difference better, visually, which prompted this GitHub issue.

[...] I'm not even seeing why it should be added at all (especially if there's a plugin).

For an answer, please see the original post. Specifically, "but sometimes has flickering + latency issues in Neovim while working in larger files due to how it needs to run last in Neovim's event loop to ensure accurate results."

By "larger file" I meant I've seen this even in 1000-line files. The plugin is a great attempt but not bullet proof. It's possible the plugin could be improved to scale better for larger files better but a solution in C is the best course to keep everything in-sync.

[laburnumT]

That said though, the selection image you've posted could be VISUAL
LINE or VISUAL mode, if the line(s) have a trailing whitespace
character.

This shouldn't cause confusion, as there is a visual difference between
a newline and whitespace + newline.

Image in visual mode without whitespace:

Image in visual mode with whitespace:

But I think the biggest difference that isn't shown visually is that
visual line mode will also insert a newline above. But by default vim
will tell you what visual mode you are in.

I'm not certain how this works on windows style text where I believe the
line ending is two chars (\r\n). But I assume it respects this and shows
it as one char if the fileformat is set to dos?

[ColinKennedy]

there is a visual difference between a newline and whitespace + newline.

I feel you but as mentioned, that's only the case when set listchars includes eol, which isn't a guarantee. Without eol defined, both modes show the same highlight. Even then, what's stopping the "Image in visual mode with whitespace:" image, which is a line containing a trailing whitespace + newline in VISUAL LINE mode, from actually being a line with two whitespaces in VISUAL mode? They'd show the same in either case. In my opinion the two images are not a big enough difference to be noticeable and even if paying attention it's still possible to confuse them.

The crux of the matter IMO is that, in VISUAL mode, you need to know exactly what characters you're selecting so that you know how that text might [p]ut later. So it makes sense to highlight those characters exactly as it is right now. However in VISUAL LINE there is exactly one [p]ut behavior. In VISUAL LINE mode, the intent is "I don't care what characters exist here, whitespace or newlines or otherwise, I want the whole line" and [p]ut also reflects that. The visual selection doesn't currently communicate that intent as well.

I'm not certain how this works on windows style text where I believe the line ending is two chars (\r\n). But I assume it respects this and shows it as one char if the fileformat is set to dos?

I use both Windows and CentOS and they both appear to operate the same in both cases so I think this isn't as much of a concern thankfully but I could be wrong.

Btw @laburnumT thank you for chatting this out instead of outright dismissing the suggestion. I know this is a small quality of life thing but I think it's worth at least chatting about!

[laburnumT]

Hmm the listchars thing could indeed make it visually confusing, though
I'm not sure how confusing it would actually be to a new user. But
without listchars having eol there is also an issue in visual mode,
because you are taking the newline, but it's not visually represented.
But I guess this is an active choice for people who change the default.

Conceptually I do like the idea of having a different visual indication
of the selection between the modes, but I'm not sure losing the ability
to see whether you're copying whitespace is worth it.

Perhaps something with autocmds could set a visible eol char when
entering visual line mode, and remove it again when exiting it. That
could be added to a vimrc if needed. Something simple like this works
for me, but could be slightly more complex if you have a more custom
listchars:

augroup vlineStuff
  autocmd!
  autocmd ModeChanged * if mode() == "V" | set list  | endif
  autocmd ModeChanged * if mode() != "V" | set list& | endif
augroup END

[ColinKennedy]

Conceptually I do like the idea of having a different visual indication of the selection between the modes, but I'm not sure losing the ability to see whether you're copying whitespace is worth it.

The VISUAL LINE is a line-based operation so I'm unsure why a person needs to know, during that moment, whether they're selecting trailing whitespace. Whether the line has whitespace or not, VISUAL LINE selects the line all the same. If someone did want specifically to know whether their selection has trailing whitespace, they would use VISUAL mode, which is the mode meant for selecting characters. Or use set listchars=trail:c so they can see the characters as text. Or if not they could highlight it differently by using their colorscheme. But that's outside the scope of this GitHub issue.

The suggested autocmd would only work in base Vim, Neovim doesn't set eol by default. I'm not saying Vim needs to accommodate Neovim here but it goes to show how inconsistent the user experience VISUAL LINE in Vim currently can be.

I've said all of my main points. I still think this suggestion is pretty inline with the spirit of VISUAL LINE. Even if it's just an opt-in feature I think it'd be a good addition!