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

[Eli Zaretskii]

> Date: Sun, 16 Jan 2022 22:58:34 +1300
> From: Phil Sainty <psainty@orcon.net.nz>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, 52163@debbugs.gnu.org,
>  iung@autistici.org
> 
> On 2022-01-16 20:22, Eli Zaretskii wrote:
> > Where do you want Emacs to place the cursor when there's no
> > whitespace at end of visual line?
> > 
> > IOW, before declaring that there is a problem, please be sure to
> > consider any reasonable solutions.
> 
> In this scenario I would expect it to place the cursor on the final
> character of the original visual line, rather than the first character
> of the subsequent visual line.

But that is contrary to the documentation of end-of-visual-line.  So
before long, someone else will file a bug report about such a
behavior.

> If you do C-a C-e C-a and the two C-a commands take you to two
> different positions (and indeed different lines), I think that is very
> strange indeed.

It isn't strange if you consider the buffer contents and the
documentation of what C-a and C-e should be doing in that mode.

> Regardless of the solution, there is no whitespace for the cursor to
> be positioned at, so I think the decision to use position N+1 rather
> than N seems somewhat arbitrary, and unintuitive as a "Move point to
> end of current line" behaviour.

The cursor is positioned after the end of the visual line.  How is
that "arbitrary"??

> I expect the counter argument is that the first character of the next
> line *is* the position at the end of the visual line if it's not
> possible to break that line (i.e. the region between the C-a and C-e
> positions is indeed the entire visual line); but I think visual lines
> are such a dynamic notion to begin with (depending on window width,
> font size, etc, etc), and the "end" of an unbreakable line an even
> fuzzier notion, that using the position of the last char of that line
> doesn't seem like it would be very problematic for most users.

It will cause the character the user types to be inserted at a wrong
place, for starters.

> A user option to select between the two behaviours would be nice.

Feel free to submit patches to provide such an optional behavior.
>From my POV, the current behavior is exactly right and according to
the documentation.  It might be surprising at first sight, but the
entire situation with an unbreakable line cannot make much sense in
this mode.  We already jump through many hoops to support the
borderline cases in that mode.