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: Stefan Monnier
Subject: bug#19200: Point adjustemnt moves *into* invisible text
Date: Wed, 23 Mar 2016 11:32:29 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux)

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

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

> (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.

E.g. if you use overlays to make the text invisible, then (by default)
the position's invisibility is the same as the following character's
(which is what you seem to  like).  For text-properties, by default it's
the reverse (i.e. the position's visibility is the same as the
*preceding* character).

> 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.
The only real problem is that people don't realize that the reality
is more complex than what they expect.

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

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.

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.


        Stefan





reply via email to

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