[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:42:34 +0200 |
> 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?
- bug#19200: Point adjustemnt moves *into* invisible text, (continued)
- bug#19200: Point adjustemnt moves *into* invisible text, Stefan Monnier, 2016/03/21
- bug#19200: Point adjustemnt moves *into* invisible text, Eli Zaretskii, 2016/03/22
- bug#19200: Point adjustemnt moves *into* invisible text, Stefan Monnier, 2016/03/22
- bug#19200: Point adjustemnt moves *into* invisible text, Eli Zaretskii, 2016/03/22
- bug#19200: Point adjustemnt moves *into* invisible text, Stefan Monnier, 2016/03/22
- bug#19200: Point adjustemnt moves *into* invisible text, Eli Zaretskii, 2016/03/23
- bug#19200: Point adjustemnt moves *into* invisible text, Stefan Monnier, 2016/03/23
- bug#19200: Point adjustemnt moves *into* invisible text,
Eli Zaretskii <=
- bug#19200: Point adjustemnt moves *into* invisible text, Stefan Monnier, 2016/03/23
- bug#19200: Point adjustemnt moves *into* invisible text, Eli Zaretskii, 2016/03/31
- bug#19200: Point adjustemnt moves *into* invisible text, Stefan Monnier, 2016/03/31
- bug#19200: Point adjustemnt moves *into* invisible text, Michael Heerdegen, 2016/03/31
- bug#19200: Point adjustment moves *into* invisible text, John Wiegley, 2016/03/26
- bug#19200: Point adjustemnt moves *into* invisible text, Eli Zaretskii, 2016/03/21
- bug#19200: Point adjustemnt moves *into* invisible text, Michael Heerdegen, 2016/03/21