GNU bug report logs - #18417
24.3.93; posn-at-point confused by fill-column-indicator

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alp Aker <alptekin.aker <at> gmail.com>
Cc: 18417 <at> debbugs.gnu.org, dgutov <at> yandex.ru
Subject: Re: 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 <alptekin.aker <at> gmail.com>
> Cc: Dmitry <dgutov <at> yandex.ru>, 18417 <at> debbugs.gnu.org
> 
> > 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.

Previous Next

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