GNU bug report logs - #19200
Point adjustment moves *into* invisible text

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: michael_heerdegen <at> web.de, jonas <at> bernoul.li, 19200 <at> debbugs.gnu.org
Subject: bug#19200: Point adjustemnt moves *into* invisible text
Date: Wed, 23 Mar 2016 12:10:26 -0400

> But we display characters, not positions.  And the cursor is displayed
> "on" some character as well.

Yes.  And from that point of view, there's no difference whether point
is at position 3, 4, or 5: the display will be the same.

So the choice of whether to put point at 3, 4, or 5 can't be just based
on "what it looks like" but on what happens when the user performs
an operation.

And "The Right Thing" will then depend on the operation, and the reason
why the text was made invisible.  Which is why the chosen position needs
to be controllable (the fact that it's controlled by stickiness is
somewhat arbitrary in this respect).

The choice of using stickiness is based on the idea that an important
operation is insertion, in which case it's important to make sure that
when the user moves around and edits a buffer that has invisible text,
she doesn't end up inserting text that's invisible (and hence get the
impression that the insertion somehow didn't even happen).

> And it isn't important what I remember, because above I was talking
> about what the display code does: it examines properties of characters
> using the likes of get-char-property, and behaves accordingly.

I still don't see any relationship with point-adjustment.

>> > 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.)
>> AFAIK there's no relevant interaction with the display engine.
> Read the code: it's all over the place.  Why do you think
> vertical-motion ends up at position 5 in the test case you presented
> in this bug report?

I don't see how that relates.  Point-adjustment has to work regardless
of which command was used, and point can end up at position 4 or
5 rather than position 3 for all kinds of reasons unrelated to
invisibility, so if vertical-motion goes to position 5, it's really (or
at least should be) a non-issue for point-adjustment.

>> The issue of the main bug is not so much that we don't know how to fix
>> it, but that noone has bothered to investigate it to try and figure out
>> what is actually happening.
> Didn't I do that?  Doesn't the fact that the relevant code calls
> get-char-property-and-overlay explain what happens?

No: the get-char-property-and-overlay calls will only determine the
boundaries of the invisible text (i.e. they should find that the
invisible chunk goes between 3 and 5).

After that, adjust_point_for_property should start by moving point to
position 3 (because last_pt should be < 3).

And after that it should use Fget_pos_property to decide whether to stay
at position 3 or to move to position 5, and in this case it should
choose to stay at position 3.

So someone needs to step through the code and figure out why this
doesn't happen.  E.g. maybe it doesn't happen because
adjust_point_for_property is not called at all.


        Stefan

Previous Next

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