unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
* posn-at-point and display properties
@ 2011-02-24  9:14 ata
  0 siblings, 0 replies; only message in thread
From: ata @ 2011-02-24  9:14 UTC (permalink / raw)
  To: help-gnu-emacs

I believe this to be a bug, but I'm not certain, so I'm posting here
first.  For reference, I'm using 23.2.1 on MacOS.

When posn-at-point is called with an argument POS that's within a text
interval with a non-nil display property, the column it reports is the
column after whatever is displayed.  But (and this is what's confusing
me) it reports the same column for a POS at the start of such an
interval.  Thus, when the cursor is positioned immediately *before* a
display, posn-at-point will return a column for point that is at the
*end* of the display.

This can lead navigation commands to behave in unintuitive fashion.
For example, it will cause next-line to jump columns when line-move-
visual is non-nil. Evaluation of the following form illustrates the
problem:

(progn
  (goto-char 1)
  (insert "foo foo foo\n" "bar bar bar\n")
  (put-text-property 5 8 'display "XXX")
  (goto-char 5); point is now before XXX, in column 4
  (setq col1 (current-column))
  (setq line-move-visual t)
  (next-line); point is now on the next line, in column 7
  (setq col2 (current-column)))

col1
 => 4
col2
 => 7

The same problem arises with pos-visible-in-window-p, and seems
ultimately traceable to pos_visible_p from xdisp.c.

Is this behavior intended, or should I submit a bug report?


^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2011-02-24  9:14 UTC | newest]

Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-02-24  9:14 posn-at-point and display properties ata

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).