GNU bug report logs - #39098
26.3; bug of mouse-face including linebreak

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 39098 in the body.
You can then email your comments to 39098 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: 26.3; bug of mouse-face including linebreak
Date: Sun, 12 Jan 2020 22:32:31 +0900

If 'mouse-face is put on a reaion including linebreaks and active,
the appearance of the blank areas right to linebreaks is changed.
But pointing the blank areas does not activate 'mouse-face.

If 'mouse-face is put on a region ending with a linebreak,
the activated appearance covers the first character of the next line.

Example:
Evaluating the form below, a green area is displayed, where 'face,
'mouse-face, 'keymap and 'help-echo properties are put.
The green area includes a text "TARGET" and a blank area.

When pointing "TARGET", 'mouse-face is active.
The red area covers "*" in the next line, which has no properties.
When pointting the green blank area, 'mouse-face is not active.

Clicking the green area(both "TARGET" and the blank area) shows a
message "mouse-face: (:background red)".
The keymap is also active at "*" in the next line, which has no
properties.

The 'help-echo property is active only when pointing on "TARGET", not on
the green blank area.

(let ((map (make-sparse-keymap)))
  (switch-to-buffer (generate-new-buffer "tmp"))
  (define-key map [down-mouse-1] #'ignore)
  (define-key map [mouse-1]
    (lambda (ev)
      (interactive "e")
      (let* ((p (posn-point (event-end ev)))
             (prop (get-text-property p 'mouse-face)))
        (message "mouse-face: %s" prop))))
  (define-key map "e" 'end-of-line)
  (insert "before\n"
          (propertize "TARGET\n"
                      'face '(:background "green")
                      'mouse-face '(:background "red")
                      'help-echo "click here"
                      'keymap map)
        "*after\n"))



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 6.3.9600
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: 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
  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 sort mail-extr emacsbug message rmc puny seq dired
dired-loaddefs format-spec rfc822 mml mml-sec password-cache epa derived
epg epg-config gnus-util rmail rmail-loaddefs mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail
rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils cus-edit
cus-start cus-load wid-edit pulse eieio-opt speedbar sb-image ezimage
dframe find-func thingatpt xref cl-seq project ring eieio eieio-core
cl-macs eieio-loaddefs misearch multi-isearch cl-extra help-fns
radix-tree cl-print byte-opt gv bytecomp byte-compile cconv debug
help-mode easymenu 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 139841 14457)
 (symbols 48 25226 1)
 (miscs 40 189 298)
 (strings 32 39872 1327)
 (string-bytes 1 1014280)
 (vectors 16 18882)
 (vector-slots 8 687654 27462)
 (floats 8 69 402)
 (intervals 56 1657 975)
 (buffers 992 20))

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: ynyaaa <at> gmail.com
Cc: 39098 <at> debbugs.gnu.org
Subject: Re: bug#39098: 26.3; bug of mouse-face including linebreak
Date: Sun, 12 Jan 2020 17:16:30 +0200

tags 39098 notabug
thanks

> From: ynyaaa <at> gmail.com
> Date: Sun, 12 Jan 2020 22:32:31 +0900
> 
> If 'mouse-face is put on a reaion including linebreaks and active,
> the appearance of the blank areas right to linebreaks is changed.
> But pointing the blank areas does not activate 'mouse-face.
> 
> If 'mouse-face is put on a region ending with a linebreak,
> the activated appearance covers the first character of the next line.

This is not a bug, this is how mouse-face is supposed to work.  It
differs from other faces in this regard, because it is intended to be
used to show mouse-sensitive text, including text that spans multiple
lines.

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

From: ynyaaa <at> gmail.com
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 39098 <at> debbugs.gnu.org
Subject: Re: bug#39098: 26.3; bug of mouse-face including linebreak
Date: Mon, 13 Jan 2020 15:53:07 +0900

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

> tags 39098 notabug
> thanks
>
>> From: ynyaaa <at> gmail.com
>> Date: Sun, 12 Jan 2020 22:32:31 +0900
>> 
>> If 'mouse-face is put on a reaion including linebreaks and active,
>> the appearance of the blank areas right to linebreaks is changed.
>> But pointing the blank areas does not activate 'mouse-face.
>> 
>> If 'mouse-face is put on a region ending with a linebreak,
>> the activated appearance covers the first character of the next line.
>
> This is not a bug, this is how mouse-face is supposed to work.  It
> differs from other faces in this regard, because it is intended to be
> used to show mouse-sensitive text, including text that spans multiple
> lines.

Why is the out-of-range character highlighted only if it is at the
beginning of line?

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: ynyaaa <at> gmail.com
Cc: 39098 <at> debbugs.gnu.org
Subject: Re: bug#39098: 26.3; bug of mouse-face including linebreak
Date: Mon, 13 Jan 2020 10:01:49 +0200

On January 13, 2020 8:53:07 AM GMT+02:00, ynyaaa <at> gmail.com wrote:
> 
> Why is the out-of-range character highlighted only if it is at the
> beginning of line?

Because you've covered the newline with mouse-face.  Newlines leave no glyphs on display, so the next character gets highlighted instead.  If you don't want this, exclude the newline from the mouse-face propertized part, it is unnecessary anyway, because a newline can never be "mouse-sensitive".

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

From: ynyaaa <at> gmail.com
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 39098 <at> debbugs.gnu.org
Subject: Re: bug#39098: 26.3; bug of mouse-face including linebreak
Date: Mon, 13 Jan 2020 23:44:51 +0900

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

> On January 13, 2020 8:53:07 AM GMT+02:00, ynyaaa <at> gmail.com wrote:
>> 
>> Why is the out-of-range character highlighted only if it is at the
>> beginning of line?
>
> Because you've covered the newline with mouse-face.  Newlines leave no
> glyphs on display, so the next character gets highlighted instead.  If
> you don't want this, exclude the newline from the mouse-face
> propertized part, it is unnecessary anyway, because a newline can
> never be "mouse-sensitive".

Conversely, is there any way to disable 'mouse-face hilighting at blank
areas when the region contains more than two lines?
Just like 'underline face does not draw line to the right edge.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: ynyaaa <at> gmail.com
Cc: 39098 <at> debbugs.gnu.org
Subject: Re: bug#39098: 26.3; bug of mouse-face including linebreak
Date: Mon, 13 Jan 2020 18:40:21 +0200

> From: ynyaaa <at> gmail.com
> Cc: 39098 <at> debbugs.gnu.org
> Date: Mon, 13 Jan 2020 23:44:51 +0900
> 
> Conversely, is there any way to disable 'mouse-face hilighting at blank
> areas when the region contains more than two lines?
> Just like 'underline face does not draw line to the right edge.

Maybe, I will need to check.  (Btw, the highlighting affects the empty
space past EOL only if you specify the background color; if you
specify 'underline' or something similar, it doesn't affect the empty
space.)

Suggest to file a feature-request bug report about that.

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

From: Stefan Kangas <stefan <at> marxist.se>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: ynyaaa <at> gmail.com, 39098-done <at> debbugs.gnu.org
Subject: Re: bug#39098: 26.3; bug of mouse-face including linebreak
Date: Thu, 23 Jan 2020 06:09:07 +0100

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

> tags 39098 notabug
> thanks
>
>> From: ynyaaa <at> gmail.com
>> Date: Sun, 12 Jan 2020 22:32:31 +0900
>> 
>> If 'mouse-face is put on a reaion including linebreaks and active,
>> the appearance of the blank areas right to linebreaks is changed.
>> But pointing the blank areas does not activate 'mouse-face.
>> 
>> If 'mouse-face is put on a region ending with a linebreak,
>> the activated appearance covers the first character of the next line.
>
> This is not a bug, this is how mouse-face is supposed to work.  It
> differs from other faces in this regard, because it is intended to be
> used to show mouse-sensitive text, including text that spans multiple
> lines.

I'm therefore also closing this bug.

Best regards,
Stefan Kangas

Previous Next

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