bug#52163: 28.0.60; visual-line-mode breaks C-a and C-e in extreme case

[Eli Zaretskii]

> Date: Sun, 16 Jan 2022 23:55:39 +1300
> From: Phil Sainty <psainty@orcon.net.nz>
> Cc: larsi@gnus.org, 52163@debbugs.gnu.org, iung@autistici.org
> 
> I've just remembered `overflow-newline-into-fringe'.  AFAIK that only
> has an effect on lines which are *exactly* the window-width characters
> wide, but it occurs to me that this fringe behaviour/visualisation
> could be used to create a more intuitive solution for the unbreakable
> visual line situation, allowing C-e to visually position the cursor at
> the end of the visual line (in the fringe) rather than the start of
> the next line.

This will cause other problems.

> It might be quite a special-case approach -- the fringe position would
> be the same position as the start of the next visual line, so Emacs
> would need a way to decide which of those two visual places to render
> the cursor; and in order for C-a to then move to the start of the same
> visual line Emacs would need to know that it had previously been
> rendering the cursor in the fringe, so probably the C-a and C-e
> commands would be handling this explicitly.

Exactly.  And since overflow-newline-into-fringe is implemented in the
display engine, any information about which commands got us there
cannot be relied upon.

Moreover, this isn't exactly what overflow-newline-into-fringe is
about.  That feature is used when point is on the newline that ends a
line.  Since the newline has no visual representation, we can put the
cursor on the fringe, and C-f/C-b still do what is expected.  Not so
in this case, where point is actually on the first character of the
next screen line.

> It sounds kinda fiddly/complicated, and I'm not requesting that anyone
> tackle this, but I wanted to describe the idea here in case anyone
> else thinks it's worth looking into.

Thanks.