bug#39098: 26.3; bug of mouse-face including linebreak

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

bug#39098: 26.3; bug of mouse-face including linebreak

ynyaaa

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



Reply | Threaded
Open this post in threaded view
|

bug#39098: 26.3; bug of mouse-face including linebreak

Eli Zaretskii
tags 39098 notabug
thanks

> From: [hidden email]
> 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.



Reply | Threaded
Open this post in threaded view
|

bug#39098: 26.3; bug of mouse-face including linebreak

ynyaaa
Eli Zaretskii <[hidden email]> writes:

> tags 39098 notabug
> thanks
>
>> From: [hidden email]
>> 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?



Reply | Threaded
Open this post in threaded view
|

bug#39098: 26.3; bug of mouse-face including linebreak

Eli Zaretskii
On January 13, 2020 8:53:07 AM GMT+02:00, [hidden email] 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".



Reply | Threaded
Open this post in threaded view
|

bug#39098: 26.3; bug of mouse-face including linebreak

ynyaaa
Eli Zaretskii <[hidden email]> writes:

> On January 13, 2020 8:53:07 AM GMT+02:00, [hidden email] 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.



Reply | Threaded
Open this post in threaded view
|

bug#39098: 26.3; bug of mouse-face including linebreak

Eli Zaretskii
> From: [hidden email]
> Cc: [hidden email]
> 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.