[Top][All Lists]

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

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

From: Eli Zaretskii
Subject: bug#25906: 25.1; strange behavior of overlapped mouse-face
Date: Fri, 03 Mar 2017 20:29:21 +0200

> From: Glenn Morris <address@hidden>
> Cc: address@hidden,  address@hidden,  address@hidden
> 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.

reply via email to

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