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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 22 Aug 2014 04:58:55 +0400
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: 18285@debbugs.gnu.org
> 
> On 08/21/2014 08:06 PM, Eli Zaretskii wrote:
> 
> >> 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.
> 
> Okay, but I'll take this to mean that hitting the changed behavior in 
> existing code would be pretty rare.

I have no idea how rare it will be.  FWIW, for the past year, all the
display-related bugs are for pretty rare cases.  What does that tell
you about user expectations?

> Anyway, how about the other way around? I'll like this less, but why not 
> make `invisible' inactive when `display' is set?

That's what Emacs does already.  The only place where invisible still
matters in this situation is when deciding how and where to display
overlay strings.  I thought I explained that earlier in this thread.

> >> 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.
> 
> I'm just quoting Stefan from that discussion:
> 
> """
> Same problem: for two overlays of equal `priority', the shorter one has
> higher priority, so your original example is already one of those
> cases, AFAIC.
> """

This again omits the basic fact that properties and overlays are per
character.

> (let ((pt (point)))
>    (insert "aaa")
>    (let ((o (make-overlay pt (point))) (v (make-overlay (1+ pt) (1- 
> (point)))))
>      (overlay-put o 'face 'bold)
>      (overlay-put v 'face 'default)))
> 
> the middle character has normal weight, even though it's also covered by 
> an outer overlay that sets `face' to `bold'.
> 
> So, if I had to pick which single string to show (STRING1 or STRING2), 
> the latter seems to be the more consistent choice.

My opinion is that users and Lisp programmers should not enter these
dark corners.