GNU bug report logs - #39245
26.3; 'mouse-face highlighting is extended beyond EOB

Previous Next

To reply to this bug, email your comments to 39245 AT debbugs.gnu.org.

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: 26.3; 'mouse-face highlighting is extended beyond EOB
Date: Thu, 23 Jan 2020 11:05:06 +0900

If a buffer does not end with a newline and 'mouse-face property is
added at the last character, 'mouse-face highlighting covers the blank
area to the right of the last character.

If 'mouse-face region contains newline characters,
the blank area to the right of the last character is not highlighted.

Example: Evaluate the form below and move the mouse pointer onto 'XYZ'.
Then the blank area to the right of 'Z' is highlighted.
If a newline character is inserted between 'X' and 'Y',
the blank area to the right of 'Z' is not highlighted.

  (let ((buf (generate-new-buffer "tmp")))
    (switch-to-buffer buf)
    (insert (propertize "XYZ" 'mouse-face 'region)))


In GNU Emacs 26.3 (build 1, x86_64-w64-mingw32)
 of 2019-08-29 built on CIRROCUMULUS
Repository revision: 96dd0196c28bc36779584e47fffcca433c9309cd
Windowing system distributor 'Microsoft Corp.', version 10.0.18363
Recent messages:

Configured using:
 'configure --without-dbus --host=x86_64-w64-mingw32
 --without-compress-install 'CFLAGS=-O2 -static -g3''

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

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

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  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

Load-path shadows:
None found.

Features:
(shadow emacsbug mailalias smtpmail sendmail sort mail-extr message
dired dired-loaddefs rfc822 mml mml-sec epa derived epg epg-config
mm-decode mm-bodies mm-encode mailabbrev gmm-utils mailheader help-fns
radix-tree pp descr-text cl-extra help-mode network-stream starttls
url-http tls gnutls mail-parse rfc2231 url-gw nsm rmc url-cache url-auth
eww easymenu puny mm-url gnus nnheader gnus-util rmail rmail-loaddefs
rfc2047 rfc2045 ietf-drums mail-utils wid-edit mm-util mail-prsvr
url-queue url url-proxy url-privacy url-expand url-methods url-history
url-cookie url-domsuf url-util url-parse auth-source cl-seq eieio
eieio-core cl-macs eieio-loaddefs password-cache url-vars mailcap shr
svg xml seq byte-opt gv bytecomp byte-compile cconv dom browse-url
format-spec cl-loaddefs cl-lib elec-pair time-date mule-util japan-util
tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type
mwheel dos-w32 ls-lisp disp-table term/w32-win w32-win w32-vars
term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow isearch timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors 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 composite charscript charprop case-table epa-hook jka-cmpr-hook
help simple abbrev obarray 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 threads w32notify w32 lcms2 multi-tty make-network-process
emacs)

Memory information:
((conses 16 161708 174502)
 (symbols 48 49361 1)
 (miscs 40 54 395)
 (strings 32 109842 2812)
 (string-bytes 1 2498276)
 (vectors 16 24952)
 (vector-slots 8 1685746 190664)
 (floats 8 79 505)
 (intervals 56 14250 4622)
 (buffers 992 15))

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: ynyaaa <at> gmail.com
Cc: 39245 <at> debbugs.gnu.org
Subject: Re: bug#39245: 26.3; 'mouse-face highlighting is extended beyond EOB
Date: Wed, 28 Oct 2020 13:36:09 +0100

ynyaaa <at> gmail.com writes:

> If a buffer does not end with a newline and 'mouse-face property is
> added at the last character, 'mouse-face highlighting covers the blank
> area to the right of the last character.
>
> If 'mouse-face region contains newline characters,
> the blank area to the right of the last character is not highlighted.
>
> Example: Evaluate the form below and move the mouse pointer onto 'XYZ'.
> Then the blank area to the right of 'Z' is highlighted.
> If a newline character is inserted between 'X' and 'Y',
> the blank area to the right of 'Z' is not highlighted.
>
>   (let ((buf (generate-new-buffer "tmp")))
>     (switch-to-buffer buf)
>     (insert (propertize "XYZ" 'mouse-face 'region)))

This behaviour is still present in Emacs 28.

But I'm not sure what the correct behaviour would be.  Since mouse-face
has :extend, would it make sense to also extend it at eob?  Possibly...
not?

In any case, the current behaviour is a bug -- if it should extend at
eob, it should continue to do so even if the area has a newline, I
think.  (Or not extend at eob at all.)

This is just an issue with mouse-face, face doesn't have this problem:

  (let ((buf (generate-new-buffer "tmp")))
    (switch-to-buffer buf)
    (insert (propertize "XYZ" 'face 'region)))


-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: ynyaaa <at> gmail.com, 39245 <at> debbugs.gnu.org
Subject: Re: bug#39245: 26.3; 'mouse-face highlighting is extended beyond EOB
Date: Wed, 28 Oct 2020 17:41:17 +0200

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Wed, 28 Oct 2020 13:36:09 +0100
> Cc: 39245 <at> debbugs.gnu.org
> 
> This is just an issue with mouse-face, face doesn't have this problem:
> 
>   (let ((buf (generate-new-buffer "tmp")))
>     (switch-to-buffer buf)
>     (insert (propertize "XYZ" 'face 'region)))

Mouse face is displayed in a very special way (and for very different
purposes), so this is not surprising.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: ynyaaa <at> gmail.com, 39245 <at> debbugs.gnu.org
Subject: Re: bug#39245: 26.3; 'mouse-face highlighting is extended beyond EOB
Date: Fri, 30 Oct 2020 12:37:41 +0100

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

>> This is just an issue with mouse-face, face doesn't have this problem:
>> 
>>   (let ((buf (generate-new-buffer "tmp")))
>>     (switch-to-buffer buf)
>>     (insert (propertize "XYZ" 'face 'region)))
>
> Mouse face is displayed in a very special way (and for very different
> purposes), so this is not surprising.

It was just a data point.

But what do you think of the mouse-face behaviour?  

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: ynyaaa <at> gmail.com, 39245 <at> debbugs.gnu.org
Subject: Re: bug#39245: 26.3; 'mouse-face highlighting is extended beyond EOB
Date: Fri, 30 Oct 2020 13:44:07 +0200

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: ynyaaa <at> gmail.com,  39245 <at> debbugs.gnu.org
> Date: Fri, 30 Oct 2020 12:37:41 +0100
> 
> But what do you think of the mouse-face behaviour?  

I'd be damned if I ever agree to hack that piece of code again.
Making it DTRT with bidirectional text was a heck of a ride at the
time, and I have no reason to want to take it again.

People who are annoyed enough by the corner cases presented in this
bug report are welcome to try their teeth, I promise to lend any help
I can to those brave souls.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: larsi <at> gnus.org
Cc: ynyaaa <at> gmail.com, 39245 <at> debbugs.gnu.org
Subject: Re: bug#39245: 26.3; 'mouse-face highlighting is extended beyond EOB
Date: Fri, 30 Oct 2020 13:50:11 +0200

> Date: Fri, 30 Oct 2020 13:44:07 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: ynyaaa <at> gmail.com, 39245 <at> debbugs.gnu.org
> 
> > But what do you think of the mouse-face behaviour?  
> 
> I'd be damned if I ever agree to hack that piece of code again.
> Making it DTRT with bidirectional text was a heck of a ride at the
> time, and I have no reason to want to take it again.
> 
> People who are annoyed enough by the corner cases presented in this
> bug report are welcome to try their teeth, I promise to lend any help
> I can to those brave souls.

IOW, I can live with this behavior without problems, and could even
argue it should be expected.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: ynyaaa <at> gmail.com, 39245 <at> debbugs.gnu.org
Subject: Re: bug#39245: 26.3; 'mouse-face highlighting is extended beyond EOB
Date: Sun, 01 Nov 2020 12:40:52 +0100

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

>> I'd be damned if I ever agree to hack that piece of code again.
>> Making it DTRT with bidirectional text was a heck of a ride at the
>> time, and I have no reason to want to take it again.

:-)

>> People who are annoyed enough by the corner cases presented in this
>> bug report are welcome to try their teeth, I promise to lend any help
>> I can to those brave souls.

OK, I hope somebody feels the urge to have a peek at this problem at
some time.

> IOW, I can live with this behavior without problems, and could even
> argue it should be expected.

Yes, extending to the end of the buffer could arguably be expected
behaviour...  if it did this consistently (but it doesn't do this if
there's a newline in the region, which makes it unarguably a bug, I'd,
er, argue).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

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