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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry <dgutov <at> yandex.ru>
Cc: 18417 <at> debbugs.gnu.org
Subject: Re: bug#18417: 24.3.93;
 posn-at-point confused by fill-column-indicator
Date: Sun, 07 Sep 2014 20:22:22 +0300

> From: Dmitry <dgutov <at> 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.

Previous Next

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