GNU bug report logs - #25906
25.1; strange behavior of overlapped mouse-face

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 25906 in the body.
You can then email your comments to 25906 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: ynyaaa <at> gmail.com
To: bug-gnu-emacs <at> gnu.org
Subject: 25.1; strange behavior of overlapped mouse-face
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.
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))

Message #8 received at 25906 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: ynyaaa <at> gmail.com
Cc: 25906 <at> debbugs.gnu.org
Subject: Re: bug#25906: 25.1; strange behavior of overlapped mouse-face
Date: Wed, 01 Mar 2017 19:05:10 +0200

> From: ynyaaa <at> 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.

Message #15 received at 25906 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 25906 <at> debbugs.gnu.org, ynyaaa <at> gmail.com
Subject: Re: bug#25906: 25.1; strange behavior of overlapped mouse-face
Date: Wed, 01 Mar 2017 18:35:58 -0500

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

Message #18 received at 25906 <at> debbugs.gnu.org (full text, mbox):

From: npostavs <at> users.sourceforge.net
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 25906 <at> debbugs.gnu.org, ynyaaa <at> gmail.com
Subject: Re: bug#25906: 25.1; strange behavior of overlapped mouse-face
Date: Wed, 01 Mar 2017 18:37:17 -0500

found 25906 24.3
quit

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: ynyaaa <at> 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).

Message #23 received at 25906 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: npostavs <at> users.sourceforge.net
Cc: 25906 <at> debbugs.gnu.org, ynyaaa <at> gmail.com
Subject: Re: bug#25906: 25.1; strange behavior of overlapped mouse-face
Date: Thu, 02 Mar 2017 17:05:31 +0200

> From: npostavs <at> users.sourceforge.net
> Cc: ynyaaa <at> gmail.com,  25906 <at> debbugs.gnu.org
> Date: Wed, 01 Mar 2017 18:37:17 -0500
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> From: ynyaaa <at> 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.

Message #26 received at 25906 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 25906 <at> debbugs.gnu.org, ynyaaa <at> gmail.com, npostavs <at> users.sourceforge.net
Subject: Re: bug#25906: 25.1; strange behavior of overlapped mouse-face
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.

Message #29 received at 25906 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 25906 <at> debbugs.gnu.org, ynyaaa <at> gmail.com, npostavs <at> users.sourceforge.net
Subject: Re: bug#25906: 25.1; strange behavior of overlapped mouse-face
Date: Fri, 03 Mar 2017 09:51:02 +0200

> From: Glenn Morris <rgm <at> gnu.org>
> Cc: npostavs <at> users.sourceforge.net,  25906 <at> debbugs.gnu.org,  ynyaaa <at> 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.

Message #32 received at 25906 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 25906 <at> debbugs.gnu.org, ynyaaa <at> gmail.com, npostavs <at> users.sourceforge.net
Subject: Re: bug#25906: 25.1; strange behavior of overlapped mouse-face
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.
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.

Message #35 received at 25906 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 25906 <at> debbugs.gnu.org, ynyaaa <at> gmail.com, npostavs <at> users.sourceforge.net
Subject: Re: bug#25906: 25.1; strange behavior of overlapped mouse-face
Date: Fri, 03 Mar 2017 20:29:21 +0200

> From: Glenn Morris <rgm <at> gnu.org>
> Cc: npostavs <at> users.sourceforge.net,  25906 <at> debbugs.gnu.org,  ynyaaa <at> 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.

Message #38 received at 25906 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 25906 <at> debbugs.gnu.org, ynyaaa <at> gmail.com, npostavs <at> users.sourceforge.net
Subject: Re: bug#25906: 25.1; strange behavior of overlapped mouse-face
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.

Message #43 received at 25906-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: ynyaaa <at> gmail.com, 25906-done <at> debbugs.gnu.org,
 npostavs <at> users.sourceforge.net
Subject: Re: bug#25906: 25.1; strange behavior of overlapped mouse-face
Date: Sat, 11 Mar 2017 14:28:26 +0200

> From: Glenn Morris <rgm <at> gnu.org>
> Cc: npostavs <at> users.sourceforge.net,  25906 <at> debbugs.gnu.org,  ynyaaa <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.