[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: An interesting line-motion bug.

From: Eli Zaretskii
Subject: Re: An interesting line-motion bug.
Date: Thu, 17 Nov 2022 14:24:56 +0200

> 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]