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

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: 19200@debbugs.gnu.org, michael_heerdegen@web.de, jonas@bernoul.li
> Date: Wed, 23 Mar 2016 11:32:29 -0400
> 
> >> 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"? ;-)
> 
> No: the character after position 3 is invisible, but the position 3 is not.
> Inversely, the character after position 5 is visible while the position
> is not.

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

> > 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".
> 
> No.  You just have to remember that characters are between positions and
> positions are between characters, so the two can't be conflated.

Thank you, I don't think I forgot that.

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.

> > (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.
> 
> That's not my choice and that's not hard coded.  It's the choice of the
> stickiness settings for that particular invisible property.  It can be
> controlled by text property stickiness and overlay's marker's
> insertion types.

That is not visible until you insert a character.  By contrast, the
characters and the cursor are visible at all times.

> > 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?

> The secondary bug is pretty cosmetic and (at least in this case) is
> rather helpful, so I'm not sure it would be an improvement in itself.

OK, then I don't see what can be done here.

> 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?