bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#18417: 24.3.93; posn-at-point confused by fill-column-indicator


From: Eli Zaretskii
Subject: bug#18417: 24.3.93; posn-at-point confused by fill-column-indicator
Date: Tue, 09 Sep 2014 17:38:24 +0300

> Date: Sun, 7 Sep 2014 23:11:35 -0400
> From: Alp Aker <address@hidden>
> Cc: Dmitry <address@hidden>, address@hidden
> 
> > The recipe in effect invokes undefined behavior in posn-at-point,
> > because fci-mode uses a zero-length (a.k.a. "empty") overlay to
> > place, in a very convoluted way, a stretch of whitespace followed
> > by an image, before the newline.
> [snip]
> > Since the buffer position of the newline is not "covered" by the
> > empty overlay, Emacs happily stops when it reaches the newline,
> > oblivious to the fact that on the way it produced the stretch
> > glyph of a very large width.
> 
> I'm not sure it's due to the overlay having zero length. Here's a minimal
> recipe that provokes the same behavior using a overlay of length 1 (covering
> the newline):

You are right, the length of the overlay is not the issue here.  I
mentioned that for completeness, but my wording could indeed mislead
into thinking that the zero length is the culprit.

The actual problem is that overlays with before-strings and
after-strings never "cover" (as in "conceal" or "hide") anything.  The
buffer contents is still there, so Emacs gives you the coordinates of
the buffer position on the display, not of the first glyph produced
from the overlay string.

Btw, the same will happen with cursor positioning if you remove the
'cursor' property from the overlay string, and for the same reason.





reply via email to

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