bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#11094: Wrong cursor positioning with display+invisible


From: Eli Zaretskii
Subject: bug#11094: Wrong cursor positioning with display+invisible
Date: Mon, 02 Apr 2012 05:56:34 +0300

> From: Stefan Monnier <address@hidden>
> Cc: address@hidden
> Date: Sun, 01 Apr 2012 21:06:59 -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.

> I see that the problem is not so much that all the text is covered by
> those properties, but rather that there is are contiguous texts with
> `invisible' and `display' properties.

Yes, that doesn't help, as I mentioned.

>   emacs -Q
>   (put-text-property (point-min) (+ 4 (point-min)) 'display "<>")
>   (goto-char (point-min))
> 
> 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.

> > If you still think we should support your original code, we should
> > schedule some post-24.1 redesign and refactoring.  Let me know what
> > you think.
> 
> I don't think it's a very high priority problem, but it would be good to
> try and tackle it, yes (post-24.1).

OK.

Should we close this bug, then?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]