bug#39245: 26.3; 'mouse-face highlighting is extended beyond EOB

bug#39245: 26.3; 'mouse-face highlighting is extended beyond EOB

[ynyaaa]

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

bug#39245: 26.3; 'mouse-face highlighting is extended beyond EOB

[Lars Ingebrigtsen]

ynyaaa@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

bug#39245: 26.3; 'mouse-face highlighting is extended beyond EOB

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Wed, 28 Oct 2020 13:36:09 +0100
> Cc: 39245@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.

bug#39245: 26.3; 'mouse-face highlighting is extended beyond EOB

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@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

bug#39245: 26.3; 'mouse-face highlighting is extended beyond EOB

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: ynyaaa@gmail.com,  39245@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.

bug#39245: 26.3; 'mouse-face highlighting is extended beyond EOB

[Eli Zaretskii]

> Date: Fri, 30 Oct 2020 13:44:07 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: ynyaaa@gmail.com, 39245@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.

bug#39245: 26.3; 'mouse-face highlighting is extended beyond EOB

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@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