GNU bug report logs -
#31067
27.0.50; After-string hidden by subsequent invisible text
Previous Next
Full log
Message #20 received at 31067 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
> Cc: 31067 <at> debbugs.gnu.org
> Date: Thu, 05 Apr 2018 11:55:43 -0400
>
> >> If some (or all) of the end of the overlay-with-after-string is made
> >> invisible, then the situation is much less clear and I could see
> >> arguments either way, but if I get to choose then I think it makes sense
> >> to consider that the after string is "attached" to the end of the
> >> overlay, i.e. if the end of the overlay is invisible then so is the
> >> after-string.
> > But that's exactly what happens in your original example.
>
> Hmmm.... not that I can see: the overlay covers "text" and none of it
> is hidden.
The overlay's end point is _after_ "text", and that's exactly where
the invisible text starts. And after-string _follows_ the end of
"text", so it starts where the invisible text starts.
> I guess you could pay attention to the stickiness of the boundaries
I don't think stickiness has anything to do with this. I could
explain how the particular implementation of these features causes the
after-string to be skipped in this case, but I prefer that we first
establish the principles and the concepts. From my POV, the
implementation does what it does because it considers after-string,
conceptually, to _follow_ the end-point of the overlay, and in this
case what follows it is invisible.
> And think this one is even more
> clearly a bug, because according to stickiness the two overlays "don't
> touch" (as can be tested by carefully moving point right after the "t" and
> inserting "-" which gives you a display of "text!after!-" showing that
> the "-" was inserted between the two overlays rather than into the
> first or into the second or into both).
They cannot "not touch", because there's nothing between 'after
"text"' and 'before the following point'. The fact that inserting a
character behaves in some specific way doesn't matter, because the
display engine doesn't (and shouldn't) consider stickiness, it only
considers which display elements follow which.
> I meant "if the last few chars covered by the overlay (or the whole
> text covered by the overlay) is made invisible ...".
And that's what happens: the overlay's end-point is made invisible.
This bug report was last modified 7 years and 71 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.