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

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

[iung--- via Bug reports for GNU Emacs, the Swiss army knife of text editors]

* Reproducing
- Case 1:
   emacs -Q
   C-u 999 a
   visual-line-mode
   C-p C-a
   C-e C-a

* Notes
Most likely C-a won't move cursor in given scenario and C-e do C-n in
effect. No bug with emacs -nw.

For smaller line C-e can sometimes move cursor before last displayed
character on line. This works with emacs -nw
Increase or decrease text-scale to make this behaviour appear/

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

[Eli Zaretskii]

> Date: Sun, 28 Nov 2021 14:49:04 +0000
> From: iung--- via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> * Reproducing
> - Case 1:
>    emacs -Q
>    C-u 999 a
>    visual-line-mode
>    C-p C-a
>    C-e C-a

What are the problems you see in this recipe?  Please be specific,
because it could be that what you see on your system we cannot see on
ours.

Also, please show all the information about your build collected by
report-emacs-bug, it could be important while investigating this
issue.

> Increase or decrease text-scale to make this behaviour appear/

If you see problems when you change the text scale, it's because the
screen line's width isn't an integral multiple of the character width.
That's normal and isn't a bug (not one we'd like to fix, anyway).

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> * Reproducing
>> - Case 1:
>>    emacs -Q
>>    C-u 999 a
>>    visual-line-mode
>>    C-p C-a
>>    C-e C-a
>
> What are the problems you see in this recipe?  Please be specific,
> because it could be that what you see on your system we cannot see on
> ours.
>
> Also, please show all the information about your build collected by
> report-emacs-bug, it could be important while investigating this
> issue.

More information was requested, but no response was given within a
month, so I'm closing this bug report.  If the problem still exists,
please respond to this email and we'll reopen the bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Phil Sainty]

> Eli Zaretskii <eliz@gnu.org> writes:
> 
>>> * Reproducing
>>> - Case 1:
>>>    emacs -Q
>>>    C-u 999 a
>>>    visual-line-mode
>>>    C-p C-a
>>>    C-e C-a
>> 
>> What are the problems you see in this recipe?  Please be specific,
>> because it could be that what you see on your system we cannot see
>> on ours.

I just tried that recipe, and with visual-line-mode (and
line-move-visual) enabled C-e certainly doesn't behave how I'd expect.

Rather than C-e moving to the end of the current visual line, if the
current visual line wraps then it moves to the beginning of the next
visual line.  If I repeatedly press C-e, the cursor moves vertically
down the first column of all those visual lines.  Only the final
visual line of the logical line will it move to the end.

I'm seeing this in both 27.2 and GNU Emacs 28.0.90.

Further testing indicates that the lack of any spaces in the wrapped
visual lines is a factor.  In a visual line with a space, the visual
line will *end* with a space, and C-a will move to that.

In this recipe there are no such spaces, and the problem arises.


-Phil

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

[Eli Zaretskii]

On January 16, 2022 12:53:21 AM GMT+02:00, Phil Sainty <psainty@orcon.net.nz> wrote:
> > Eli Zaretskii <eliz@gnu.org> writes:
> > 
> >>> * Reproducing
> >>> - Case 1:
> >>>    emacs -Q
> >>>    C-u 999 a
> >>>    visual-line-mode
> >>>    C-p C-a
> >>>    C-e C-a
> >> 
> >> What are the problems you see in this recipe?  Please be specific,
> >> because it could be that what you see on your system we cannot see
> >> on ours.
> 
> I just tried that recipe, and with visual-line-mode (and
> line-move-visual) enabled C-e certainly doesn't behave how I'd expect.
> 
> Rather than C-e moving to the end of the current visual line, if the
> current visual line wraps then it moves to the beginning of the next
> visual line.  If I repeatedly press C-e, the cursor moves vertically
> down the first column of all those visual lines.  Only the final
> visual line of the logical line will it move to the end.
> 
> I'm seeing this in both 27.2 and GNU Emacs 28.0.90.
> 
> Further testing indicates that the lack of any spaces in the wrapped
> visual lines is a factor.  In a visual line with a space, the visual
> line will *end* with a space, and C-a will move to that.
> 
> In this recipe there are no such spaces, and the problem arises.

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.

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

[Phil Sainty]

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.

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.

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.

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.

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


-Phil

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.

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

[Eli Zaretskii]

> Date: Sun, 16 Jan 2022 12:18:26 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 52163@debbugs.gnu.org, larsi@gnus.org, iung@autistici.org
> 
> > 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.

Also, under the behavior you propose, what would be the result of C-b
after C-e in this case?

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

[Phil Sainty]

You've convinced me that the existing behaviour isn't a bug, and as
I'm not likely to try to add an alternative this can probably be
closed again (if it was actually re-opened).

I did have one more idea on the matter, though...

On 2022-01-16 23:18, Eli Zaretskii wrote:
>> > IOW, before declaring that there is a problem, please be sure to
>> > consider any reasonable solutions.

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.

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.

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.


-Phil

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.

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

[Phil Sainty]

On 2022-01-16 23:23, Eli Zaretskii wrote:
>> > 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.
>> 
> what would be the result of C-b after C-e in this case?

In that quoted suggestion of mine the C-e would have moved the cursor
to the position 1 character before the end of the visual line, so C-b
would move it an additional character backwards (as normal), leaving
it two chars from the visual end of the line.

My suggestion was predicated on an assumption that the user wouldn't
mind that unbreakable lines behaved differently (or rather that they
might consider that the benefit made the difference worthwhile).

(Again, I'm not pursuing this any further; I just wanted to answer
the question.)


-Phil