Highlight EOL by highlighting to the end of the terminal

[Screwtapello]

When I started using Kakoune a few months ago, it allowed the user to move the cursor onto the \n at the end of a line, but did not display any glyph there. The only ways to tell if the cursor was on the newline or just a trailing whitespace were to enable the whitespace highlighter, to hit d and see if the next line got joined, or (the most popular choice) to hit l and see if nothing happened.

Recently, Kakoune was changed so that h and l would wrap to adjacent lines, messing with people's ability to see whether their cursor was on EOL or not. To counter this, Kakoune was modified so that when a cursor is on EOL, it would be displayed in the PrimaryCursorEol/SecondaryCursorEol face rather than PrimaryCursor/SecondaryCursor.

I have some problems with this system:

• Traditionally, a selection is coloured in some shade of blue, and there aren't that many blues available in the standard 16-color terminal palette. I had previously customized SecondaryCursor to be black-on-cyan so that I could identify the primary cursor even with a 1-char selection; now if that one character is \n I'm back to my original problem again.
• For anyone who hasn't been watching the Kakoune changelog closely, it's not immediately obvious why the cursor sometimes changes colour; there's nothing inherently "blue" about EOL, and it doesn't really hint why or how changes to that character will be different from changing other other characters.

Instead, I propose an alternative behaviour: As a general rule throughout Kakoune, whenever any character in the underlying buffer takes up more than one character-space on screen, all the relevant character-spaces should be highlighted when the cursor moves over them.

• This is already true for tab characters
• This is already true for fullwidth characters like ⽊
• For newlines, this would mean highlighting all the empty space from the last character on the line, to the right-hand edge of the terminal window
• This could arguably also apply to trailing whitespace created by the wrap -word highlighter, and leading whitespace created by the wrap -indent highlighter.

Such a scheme should already be familiar to users of terminals like gnome-terminal, xterm, PuTTY and st, since their mouse selection already works this way. Even for people unfamiliar with those terminals, it should be obvious that when all the space from the end of one line to the beginning of the next is highlighted, pressing d will delete the space and join the lines together.

[lenormf]

Highlighting newlines as tabs are sounds better indeed.

[occivink]

I think that might be very noisy, visually-speaking

[Delapouite]

As you mention, I always have the white-space highlighter on, so the recent changes concerning EOL have been very smooth. I'll try to see what is the visual impact on xterm to get an idea.

[Screwtapello]

@occivink Yeah, I can definitely imagine people finding it noisy, but I feel the current system is too subtle, and I couldn't think of a good middle-ground. Maybe just highlighting the first n cells, or trying to fade out the selection colour... but those are all kind of arbitrary, where "just highlight the whole thing" feels more logical and consistent to me.

[net]

I'm also concerned about the visual noise this proposal could cause.

[mawww]

I am afraid it will really get noisy, and I am not sure that an end of line character conceptually continues up the the end of the terminal window. For tabs, their start and end position seem pretty clear, but for end of lines, I dont really think of them as something meaning "fill the rest of the line so that we end up on next line", just as something meaning "go to next line".

Similarly, when a selection spans multiple lines, it does fill the full terminal lines, only the actual characters (including the eol one).

It might be good to still try it, just to get a better idea of how it would look like.

[mawww]

Just pushed a commit on branch highlight-eol-to-window-end to let people see the impact of that change. Although its not as noisy as I expected, I am still far from convinced it is a good idea, the fact that empty lines end up fully selected feels strange in particular.

[Screwtapello]

Regardless of whether or not this behaviour reaches mainline Kakoune, thank you very much for trying it out!

I just built from that branch and spent 30 seconds trying it out myself. Initial impressions:

• When I have a "column" highlighter set up, the highlight only appears past the highlighted column
• With a multi-line selection, only the last line (if it ends at EOL) highlights to the window end; I was expecting all the lines to highlight to window-end (in PrimarySelection rather than PrimaryCursor)
• It is a bit distracting scrolling through a big file and having the cursor flash to full-width as it goes past "empty" lines

I'll keep using it for a bit and see how I feel.

[maximbaz]

My vote is also going against this proposal, but I also want to point out that the whole reason you came up with this idea is because you want to know if there are trailing whitespaces on the current line.

First of all, I don't think there is any code that requires having trailing whitespaces, and for a long time I have my editors configured to automatically remove trailing whitespaces when a file is saved. I have never heard complaints when my PR cleaned up a few extra lines in a file that I modified, plus there usually an option to hide whitespace-only changes in the diff. Maybe kakoune should just always cleanup trailing whitespaces, and then the whole problem is gone (a more general discussion about trailing whitespaces is in #2175).

Alternatively you could just add a highlighter for trailing whitespaces, and there will be no confusion where your cursor will move. It would have been cool to have an option in the built-in show-whitespaces highlighter to display symbols only when they are trailing (e.g. -trailing option), but it is not very difficult to come up with a custom solution:

define-command -hidden show-trailing-whitespaces %{ try %{ add-highlighter global/trailing-whitespaces regex '\h+$' 0:default,red } }
define-command -hidden hide-trailing-whitespaces %{ try %{ remove-highlighter global/trailing-whitespaces } }
hook global WinDisplay .*              show-trailing-whitespaces
hook global ModeChange 'insert:normal' show-trailing-whitespaces
hook global ModeChange 'normal:insert' hide-trailing-whitespaces

[dpc]

@mawww I've found a bug in the change in that branch. addhl global/ column 120 Error to repro. Probably not interesting anymore. :D