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

Previous Next

Full log

Message #36 received at 52163 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Phil Sainty <psainty <at> orcon.net.nz>
Cc: 52163 <at> debbugs.gnu.org, larsi <at> gnus.org, iung <at> autistici.org
Subject: Re: bug#52163: 28.0.60; visual-line-mode breaks C-a and C-e in
 extreme case
Date: Sun, 16 Jan 2022 13:03:51 +0200

> Date: Sun, 16 Jan 2022 23:55:39 +1300
> From: Phil Sainty <psainty <at> orcon.net.nz>
> Cc: larsi <at> gnus.org, 52163 <at> debbugs.gnu.org, iung <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.