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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sun, 7 Sep 2014 23:11:35 -0400
> From: Alp Aker <alptekin.aker@gmail.com>
> Cc: Dmitry <dgutov@yandex.ru>, 18417@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.