[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#18285: 24.3.92; A combination of `display' on text and `invisible' a

From: Eli Zaretskii
Subject: bug#18285: 24.3.92; A combination of `display' on text and `invisible' and `before/after-string' leads to the before/after string being displayed twice
Date: Thu, 21 Aug 2014 19:06:42 +0300

> Date: Thu, 21 Aug 2014 19:40:58 +0400
> From: Dmitry Gutov <address@hidden>
> CC: address@hidden
> >> After all, that was the intention behind the code I encountered this bug
> >> in. And with the current logic, like you say, if `display' is set,
> >> `invisible' is redundant.
> >
> > Yes, but not the other way around.
> If the `invisible' starts even one character earlier, it *is* the other 
> way around.

Yes, because then there's no doubt about the order of evaluating the
various properties and acting upon them.  By contrast, when they all
begin at the same buffer position, the order is
implementation-defined.  The code is written to examine display
properties before the invisible properties.

> >> Thanks. That looks very much like a bug as well, though maybe again, too
> >> expensive to fix. FWIW, for that issue, if myov2 has higher priority
> >> than myov1 (if only by virtue of being inside and shorter), I'd display
> >> just "STRING2" ("STRING1" would not be visible at all). But that's just
> >> going by logic; maybe there's a use case that would break.
> >
> > I'm quite sure there's some use case somewhere that will break.
> Maybe. But at least it's consistent with the overlay priority rules.

The priority is _per_buffer_position_.  We tend to forget that text
properties and overlays in Emacs are _character_ properties, but the
display engine is designed and implemented to support that, and in
some obscure cases, like this one, it is impossible to understand its
logic, unless one remembers this simple fact.

reply via email to

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