GNU bug report logs - #21207
25.0.50; Cursor position behaves unpredictably on the 'display text property

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: bruce.connor.am <at> gmail.com
Cc: 21207 <at> debbugs.gnu.org
Subject: bug#21207: 25.0.50; Cursor position behaves unpredictably on the 'display text property
Date: Sat, 08 Aug 2015 10:27:12 +0300

> Date: Fri, 7 Aug 2015 20:43:41 +0100
> From: Artur Malabarba <bruce.connor.am <at> gmail.com>
> Cc: 21207 <at> debbugs.gnu.org
> 
> 2015-08-07 19:23 GMT+01:00 Eli Zaretskii <eliz <at> gnu.org>:
> >> Date: Fri, 07 Aug 2015 18:29:10 +0300
> >> From: Eli Zaretskii <eliz <at> gnu.org>
> >> Cc: 21207 <at> debbugs.gnu.org
> >>
> >> > If I can place the cursor on the newline in the first scenario, why
> >> > can't I do so in the second?
> >>
> >> Because we have special support for cursor positioning on display
> >> strings that end in a newline
> >
> > More importantly: in the first scenario the newline ends the display
> > string, whereas in the second it is in its middle.
> 
> Isn't it at the start of the display string?

Yes, sorry.  The important part is that it's not at the end of the
string.

In any case, due to the way cursor positioning in these cases is
implemented, in order to decide that the cursor could be placed on a
line that is part of the display string, the display engine needs to
see at least one glyph from that display string on that line.  And a
newline leaves no glyph.  So if you change your second scenario to
this:

  (add-text-properties (point) (1+ (point)) '(display "-\n------"))

you will see that the cursor is placed on that line, before the
newline.

Previous Next

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