GNU bug report logs - #11094
Wrong cursor positioning with display+invisible

Previous Next

Package: emacs;

Reported by: Stefan Monnier <monnier <at> iro.umontreal.ca>

Date: Mon, 26 Mar 2012 04:40:01 UTC

Severity: normal

Found in version 24.0.94

Done: Stefan Monnier <monnier <at> iro.umontreal.ca>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 11094 <at> debbugs.gnu.org
Subject: bug#11094: Wrong cursor positioning with display+invisible
Date: Mon, 02 Apr 2012 09:09:34 -0400
>> > For some value of "correctly".  E.g., position the cursor over the
>> > ".", which is the first file name in the archive, and type "C-x =".
>> > You will see "63", which is a lie: the actual value of point is 111.
>> I don't think it's a lie because that text is preceded by invisible
>> text, so while "." is at 111, point is indeed at 63 (and that's just
>> because of adjust_point_for_property, so we can get point to stay at
>> 111 by being more careful with text property's stickiness).
> Having point report X when it is position on a character whose
> position is Y, or jump when you move it from one character of a file
> name to the next violates the principle of least astonishment, IMO.

That's an inevitable consequence of using `invisible'.  So yes, I agree
that `invisible' should be used with great care, but there is no bug in
this particular part (the underlying problem is that the block cursor is
drawn *on* characters whereas point is *between* characters).

>> the cursor is drawn at the right place.  I think this is the core of the
>> problem that's handled differently from Emacs-23.
>> [ IIUC you've gotten to the same conclusion.  ]
> While there could be more than one way to cut this cake, I still think
> we should encourage Lips programmers to use the `cursor' property in
> these situations.

Hmm... I haven't actually tried to use the `cursor' property, but I'm
not sure it would help when point is actually outside of the text area
covered by any of the display strings.

> Should we close this bug, then?

We might as well keep it open until the problem is actually solved.


        Stefan




This bug report was last modified 13 years and 103 days ago.

Previous Next


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