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

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

[ynyaaa]

Evaluating the form below, then move the mouse cursor on the inserted text.
When it is on aaa, underline is displayed on aaaBBB as expected.
When it is on ccc, overline is displayed on BBBccc as expected.

When it is moved holizontally from aaa to BBB, overline is not displayed.
When it is moved holizontally from ccc to BBB, underline is not displayed.
When it is moved onto BBB vertically from upside or downside,
both overline and underline are displayed on BBBccc.

(let ((p (point))
      ol-1 ol-2)
  (insert "<aaaBBBccc>\n")
  (setq ol-1 (make-overlay (+ p 1) (+ p 7))) ;; on aaaBBB
  (overlay-put ol-1 'mouse-face '(:underline t))
  (overlay-put ol-1 'evaporate t)
  (setq ol-2 (make-overlay (+ p 4) (+ p 10))) ;; on BBBccc
  (overlay-put ol-2 'mouse-face '(:overline t))
  (overlay-put ol-2 'evaporate t))




In GNU Emacs 25.1.1 (i686-w64-mingw32)
 of 2016-09-18 built on LAPHROAIG
Windowing system distributor 'Microsoft Corp.', version 6.0.6002
Configured using:
 'configure --host=i686-w64-mingw32 --without-dbus
 --without-compress-install CFLAGS=-static'

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY ACL GNUTLS LIBXML2 ZLIB
TOOLKIT_SCROLL_BARS

Important settings:
  value of $LANG: JPN
  locale-coding-system: cp932

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message dired format-spec rfc822 mml
mml-sec password-cache epg epg-config gnus-util mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail
rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils help-fns
mule-diag apropos benchmark rect misearch multi-isearch debug kmacro
two-column iso-transl help-mode easymenu cl-loaddefs pcase cl-lib
time-date mule-util japan-util tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel dos-w32 ls-lisp disp-table
w32-win w32-vars term/common-win tool-bar dnd fontset image regexp-opt
fringe tabulated-list newcomment elisp-mode lisp-mode prog-mode register
page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock
font-lock syntax facemenu font-core frame cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese charscript case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer cl-preloaded nadvice
loaddefs button faces cus-face macroexp files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote w32notify w32 multi-tty
make-network-process emacs)

Memory information:
((conses 8 107085 23454)
 (symbols 32 31013 0)
 (miscs 32 226 320)
 (strings 16 45273 5127)
 (string-bytes 1 1001128)
 (vectors 8 14127)
 (vector-slots 4 559411 5188)
 (floats 8 185 387)
 (intervals 28 1427 832)
 (buffers 520 25))

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

[Eli Zaretskii]

> From: ynyaaa@gmail.com
> Date: Wed, 01 Mar 2017 12:44:36 +0900
> 
> 
> Evaluating the form below, then move the mouse cursor on the inserted text.
> When it is on aaa, underline is displayed on aaaBBB as expected.
> When it is on ccc, overline is displayed on BBBccc as expected.
> 
> When it is moved holizontally from aaa to BBB, overline is not displayed.
> When it is moved holizontally from ccc to BBB, underline is not displayed.

I cannot reproduce this on my system.  Here the underline is displayed
no matter how I move the mouse pointer.

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

[Glenn Morris]

Eli Zaretskii wrote:

>> When it is on aaa, underline is displayed on aaaBBB as expected.
>> When it is on ccc, overline is displayed on BBBccc as expected.
>> 
>> When it is moved holizontally from aaa to BBB, overline is not displayed.
>> When it is moved holizontally from ccc to BBB, underline is not displayed.
>
> I cannot reproduce this on my system.  Here the underline is displayed
> no matter how I move the mouse pointer.

FWIW, I can reproduce it. I suspect only you can fix it though. :)

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

[npostavs]

found 25906 24.3
quit

Eli Zaretskii <eliz@gnu.org> writes:

>> From: ynyaaa@gmail.com
>> Date: Wed, 01 Mar 2017 12:44:36 +0900
>> 
>> 
>> Evaluating the form below, then move the mouse cursor on the inserted text.
>> When it is on aaa, underline is displayed on aaaBBB as expected.
>> When it is on ccc, overline is displayed on BBBccc as expected.
>> 
>> When it is moved holizontally from aaa to BBB, overline is not displayed.
>> When it is moved holizontally from ccc to BBB, underline is not displayed.
>
> I cannot reproduce this on my system.  Here the underline is displayed
> no matter how I move the mouse pointer.

I can reproduce on Windows 10 and GNU/Linux, from at least Emacs 24.3 (I
don't currently have an earlier working build).

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

[Eli Zaretskii]

> From: npostavs@users.sourceforge.net
> Cc: ynyaaa@gmail.com,  25906@debbugs.gnu.org
> Date: Wed, 01 Mar 2017 18:37:17 -0500
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: ynyaaa@gmail.com
> >> Date: Wed, 01 Mar 2017 12:44:36 +0900
> >> 
> >> 
> >> Evaluating the form below, then move the mouse cursor on the inserted text.
> >> When it is on aaa, underline is displayed on aaaBBB as expected.
> >> When it is on ccc, overline is displayed on BBBccc as expected.
> >> 
> >> When it is moved holizontally from aaa to BBB, overline is not displayed.
> >> When it is moved holizontally from ccc to BBB, underline is not displayed.
> >
> > I cannot reproduce this on my system.  Here the underline is displayed
> > no matter how I move the mouse pointer.
> 
> I can reproduce on Windows 10 and GNU/Linux, from at least Emacs 24.3 (I
> don't currently have an earlier working build).

Ah, I think I've misunderstood what is exactly strange in the
behavior.  Please describe what was expected in each case, so we are
sure we are on the same page.

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

[Glenn Morris]

Eli Zaretskii wrote:


> Please describe what was expected in each case, so we are sure we are
> on the same page.

I expect expect the appearance of the display when the cursor is at some
point (BBB) to not depend on how it got there.

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

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: npostavs@users.sourceforge.net,  25906@debbugs.gnu.org,  ynyaaa@gmail.com
> Date: Thu, 02 Mar 2017 15:42:00 -0500
> 
> Eli Zaretskii wrote:
> 
> 
> > Please describe what was expected in each case, so we are sure we are
> > on the same page.
> 
> 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.

If this is the only issue with the original behavior, then this bug
can be closed.

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

[Glenn Morris]

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.
Now it seems that overlay ol-2 always wins. Maybe this is correct, I
don't know. I think from the original report, the OP might expect both
underline and overline when the cursor is on BBB, but there is now
always only overline.

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

[Eli Zaretskii]

> 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.

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

[Glenn Morris]

Eli Zaretskii wrote:

> 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.

Makes sense to me, thanks.

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

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: npostavs@users.sourceforge.net,  25906@debbugs.gnu.org,  ynyaaa@gmail.com
> Date: Fri, 03 Mar 2017 13:36:49 -0500
> 
> Eli Zaretskii wrote:
> 
> > 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.
> 
> Makes sense to me, thanks.

No further comments, so I'm marking this bug done.

Thanks.