[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
posn-at-point and display properties
From: |
ata |
Subject: |
posn-at-point and display properties |
Date: |
Thu, 24 Feb 2011 01:14:45 -0800 (PST) |
User-agent: |
G2/1.0 |
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?
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- posn-at-point and display properties,
ata <=