bug#25906: 25.1; strange behavior of overlapped mouse-face

[Eli Zaretskii <eliz@gnu.org>]

> From: Glenn Morris <rgm@gnu.org>
> Cc: npostavs@users.sourceforge.net,  25906@debbugs.gnu.org,  ynyaaa@gmail.com
> Date: Fri, 03 Mar 2017 12:53:09 -0500
> 
> Eli Zaretskii wrote:
> 
> >> I expect expect the appearance of the display when the cursor is at some
> >> point (BBB) to not depend on how it got there.
> >
> > I agree.  This should already happen after my recent changes.
> 
> Yes, that happens now, but not in the way I was naively expecting.

That's why I asked.

> Now it seems that overlay ol-2 always wins. Maybe this is correct, I
> don't know.

It is correct, because only one overlay should be used for displaying
mouse-face, and the code selects the overlay of the highest priority.
Since the recipe didn't define any priority for the overlays, Emacs,
somewhat arbitrarily, chooses the second one.

> I think from the original report, the OP might expect both underline
> and overline when the cursor is on BBB

That would be the wrong thing to do, IMO.  The mouse-face is not just
any face, it is designed for showing an "active region" of text, where
mouse gestures produce certain effects.  Such region is also customary
has a help-echo defined to show the appropriate tooltip.  It therefore
makes no sense to merge mouse-face definitions that come from several
different sources, because there could be only one action that will
happen upon those mouse gestures, and mixing several help-echo texts
makes no sense either.  So Emacs shows only one mouse-face of several
possible ones.