all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#39098: 26.3; bug of mouse-face including linebreak
@ 2020-01-12 13:32 ynyaaa
  2020-01-12 15:16 ` Eli Zaretskii
  0 siblings, 1 reply; 7+ messages in thread
From: ynyaaa @ 2020-01-12 13:32 UTC (permalink / raw)
  To: 39098


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





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#39098: 26.3; bug of mouse-face including linebreak
  2020-01-12 13:32 bug#39098: 26.3; bug of mouse-face including linebreak ynyaaa
@ 2020-01-12 15:16 ` Eli Zaretskii
  2020-01-13  6:53   ` ynyaaa
  2020-01-23  5:09   ` Stefan Kangas
  0 siblings, 2 replies; 7+ messages in thread
From: Eli Zaretskii @ 2020-01-12 15:16 UTC (permalink / raw)
  To: ynyaaa; +Cc: 39098

tags 39098 notabug
thanks

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





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#39098: 26.3; bug of mouse-face including linebreak
  2020-01-12 15:16 ` Eli Zaretskii
@ 2020-01-13  6:53   ` ynyaaa
  2020-01-13  8:01     ` Eli Zaretskii
  2020-01-23  5:09   ` Stefan Kangas
  1 sibling, 1 reply; 7+ messages in thread
From: ynyaaa @ 2020-01-13  6:53 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 39098

Eli Zaretskii <eliz@gnu.org> writes:

> tags 39098 notabug
> thanks
>
>> From: ynyaaa@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?





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#39098: 26.3; bug of mouse-face including linebreak
  2020-01-13  6:53   ` ynyaaa
@ 2020-01-13  8:01     ` Eli Zaretskii
  2020-01-13 14:44       ` ynyaaa
  0 siblings, 1 reply; 7+ messages in thread
From: Eli Zaretskii @ 2020-01-13  8:01 UTC (permalink / raw)
  To: ynyaaa; +Cc: 39098

On January 13, 2020 8:53:07 AM GMT+02:00, ynyaaa@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".





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#39098: 26.3; bug of mouse-face including linebreak
  2020-01-13  8:01     ` Eli Zaretskii
@ 2020-01-13 14:44       ` ynyaaa
  2020-01-13 16:40         ` Eli Zaretskii
  0 siblings, 1 reply; 7+ messages in thread
From: ynyaaa @ 2020-01-13 14:44 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 39098

Eli Zaretskii <eliz@gnu.org> writes:

> On January 13, 2020 8:53:07 AM GMT+02:00, ynyaaa@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.





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#39098: 26.3; bug of mouse-face including linebreak
  2020-01-13 14:44       ` ynyaaa
@ 2020-01-13 16:40         ` Eli Zaretskii
  0 siblings, 0 replies; 7+ messages in thread
From: Eli Zaretskii @ 2020-01-13 16:40 UTC (permalink / raw)
  To: ynyaaa; +Cc: 39098

> From: ynyaaa@gmail.com
> Cc: 39098@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.





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#39098: 26.3; bug of mouse-face including linebreak
  2020-01-12 15:16 ` Eli Zaretskii
  2020-01-13  6:53   ` ynyaaa
@ 2020-01-23  5:09   ` Stefan Kangas
  1 sibling, 0 replies; 7+ messages in thread
From: Stefan Kangas @ 2020-01-23  5:09 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: ynyaaa, 39098-done

Eli Zaretskii <eliz@gnu.org> writes:

> tags 39098 notabug
> thanks
>
>> From: ynyaaa@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





^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2020-01-23  5:09 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-01-12 13:32 bug#39098: 26.3; bug of mouse-face including linebreak ynyaaa
2020-01-12 15:16 ` Eli Zaretskii
2020-01-13  6:53   ` ynyaaa
2020-01-13  8:01     ` Eli Zaretskii
2020-01-13 14:44       ` ynyaaa
2020-01-13 16:40         ` Eli Zaretskii
2020-01-23  5:09   ` Stefan Kangas

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.