all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Dmitry <dgutov@yandex.ru>
Cc: 18417@debbugs.gnu.org
Subject: bug#18417: 24.3.93; posn-at-point confused by fill-column-indicator
Date: Sun, 07 Sep 2014 20:22:22 +0300	[thread overview]
Message-ID: <837g1fcpm9.fsf@gnu.org> (raw)
In-Reply-To: <86sik513vf.fsf@yandex.ru>

> 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.





  reply	other threads:[~2014-09-07 17:22 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-06  9:43 bug#18417: 24.3.93; posn-at-point confused by fill-column-indicator Dmitry
2014-09-07 17:22 ` Eli Zaretskii [this message]
2014-09-07 18:55   ` Dmitry Gutov
2014-09-07 19:43     ` Eli Zaretskii
2014-09-07 19:52       ` Alp Aker
2014-09-07 19:56         ` Eli Zaretskii
2014-09-08  3:11   ` Alp Aker
2014-09-09 14:38     ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=837g1fcpm9.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=18417@debbugs.gnu.org \
    --cc=dgutov@yandex.ru \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.