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

[Eli Zaretskii]

> From: Dmitry <dgutov@yandex.ru>
> Date: Sat, 06 Sep 2014 13:43:00 +0400
> 
> 1. Download, put inside load-path and require fill-column-indicator.el,
> from https://github.com/alpaker/Fill-Column-Indicator.
> 2. Open an empty buffer, add a newline inside it.
> 3. Toggle fcm-mode on. Notice the indicator at the end of the empty
> line.     ^^^^^^^^

I assume you meant "fci-mode".

> 4. With point at the beginning of that line, evaluate
> 
> (posn-col-row (posn-at-point (point)))
> 
> and see it evaluate to (71 . 0).
> 
> The problem is probably not in posn-col-row, because (posn-x-y
> (posn-at-point (point))) also returns a large non-zero value in car.

This was previously reported and discussed here:

  http://lists.gnu.org/archive/html/emacs-devel/2013-07/msg00445.html

My correspondent there expressed interest in fixing this, but I never
heard from him about this since then, although I pointed him at
posn-at-point as the most probable culprit.

Anyway, I'm not going to lose sleep over this, sorry.  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.  Since "at point" means "before point", and the recipe
asks for coordinates at the newline position, it is not clear whether
the reported coordinates should or shouldn't include the stretch
glyph.  The result you see is the consequence of the implementation
details of the functions that simulate display in order to compute
screen coordinates at a given buffer position.  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.

If someone wants to work on this, patches will be welcome, of course.