Re: An interesting line-motion bug.

[Eli Zaretskii <eliz@gnu.org>]

> From: Karl Fogel <kfogel@red-bean.com>
> Date: Wed, 16 Nov 2022 23:38:32 -0600
> 
> ;; When you hit that breakpoint, point will already be on the newline
> ;; at the end of the line ";; in a buffer in which" above.  By then,
> ;; that newline has a display property that makes it look wide to
> ;; Emacs -- specifically, one unit wider than a newline normally is.
> ;; But Emacs never asked whether the display property is on a
> ;; *newline*.  In other words, Emacs identifies this as a wide
> ;; character and thus mistakenly computes a "width" that actually
> ;; extends over a vertical (because newline) span.

Why is it important that the display property "covers" a newline?  A
display property whose value is a string completely replaces the text
that it "covers", and that includes the newline in the buffer text.

What _is_ important is that the display property itself includes a
newline, which effectively resets the column to zero.

Unfortunately, I don't know how to fix this basic issue.  The code
which does that is AFAIU unable to grasp the situation where moving
across text _decreases_ the column.  If someone has ideas how to
support such situations, please speak up.  And keep in mind that this
code is used much more than for C-n and C-p.