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

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

bug#19200: Point adjustemnt moves *into* invisible text


From: Eli Zaretskii
Subject: bug#19200: Point adjustemnt moves *into* invisible text
Date: Wed, 23 Mar 2016 17:15:14 +0200

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: 19200@debbugs.gnu.org,  michael_heerdegen@web.de,  jonas@bernoul.li
> Date: Tue, 22 Mar 2016 22:13:04 -0400
> 
> >> - point adjustment doesn't bring us to position 3 after C-n
> > Why is that a problem?  Position 3 is invisible, so we shouldn't
> > expect to end up with point there.
> 
> No, you have it backwards: position 5 is invisible and position 3 is not.

So you are saying that we also have a display bug, in that what should
have been on the screen is "3" and not "5"? ;-)

> The "evidence" for that is that if you go to position 3 and insert a char,
> that char will be visible, whereas if you go to position 5 and insert
> a char, that char will be invisible.

You are talking about a different kind of "invisible", the kind that
is different from how the display engine, and any cursor-motion
commands that use its layout routines, interprets "invisible".  That
is why what you expect from the related code is hard to get: it is
barely supported by the relevant code.

(Personally, I think your notion of "invisible" is also confusing for
the user, in that it puts the cursor on a character whose position is
not the same as point.  The other notion of "invisible" also has its
disadvantages, so it's not easy to decide which one is "right", but at
least it doesn't fight an uphill battle against the display engine.)

> >> - M-: (point) has the side-effect of bringing us to position 3
> >> My guess here is that after the M-: command, at the end of
> >> command_loop_1, last_point_position refers to a position in another
> >> buffer (i.e. in the minibuffer), so it thinks there was a movement and
> >> hence re-runs adjust_point_for_property, which this time gets it right.
> > Maybe.  If this is the bug to solve, I could look into it.
> 
> No, this bug is secondary.  The main bug is that we end up at position
> 5 after C-n.

Since we don't know how to fix the main bug, would it be an
improvement to solve the secondary one?





reply via email to

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