bug#39115: 26.3; eww consecutive links look like one link with mouse-over

bug#39115: 26.3; eww consecutive links look like one link with mouse-over

[ynyaaa]

If two or more links are consecutive without any blank characters,
pointing one of them with mouse activates 'mouse-face of them all at
the same time.


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: Emacs-Lisp

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

Load-path shadows:
None found.

Features:
(mouse-copy mouse-drag novice cursor-sensor kmacro two-column iso-transl
image-mode timezone parse-time mule-diag url-http url-gw apropos
mode-local url-file url-dired url-cache url-auth eww mm-url gnus
nnheader url-queue url url-proxy url-privacy url-expand url-methods
url-history url-cookie url-domsuf url-util url-parse url-vars mailcap
shr svg xml browse-url mhtml-mode css-mode smie color js advice json map
imenu cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align
cc-engine cc-vars cc-defs sgml-mode dom thai-util thai-word lao-util
view descr-text rect info network-stream nsm starttls tls gnutls
mailalias smtpmail auth-source tabify pp 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 505645 304991)
 (symbols 48 130565 23)
 (miscs 40 674 1134)
 (strings 32 216473 52483)
 (string-bytes 1 4382744)
 (vectors 16 32416)
 (vector-slots 8 1566514 118810)
 (floats 8 283 970)
 (intervals 56 92056 5849)
 (buffers 992 38))

bug#39115: 26.3; eww consecutive links look like one link with mouse-over

[Lars Ingebrigtsen]

[-- Attachment #1: Type: text/plain, Size: 262 bytes --]

ynyaaa@gmail.com writes:

> If two or more links are consecutive without any blank characters,
> pointing one of them with mouse activates 'mouse-face of them all at
> the same time.

Here's a file that demonstrates the problem (open with `M-x eww-open-file'):


[-- Attachment #2: link.html --]
[-- Type: text/html, Size: 68 bytes --]

[-- Attachment #3: Type: text/plain, Size: 291 bytes --]


I don't know how to fix it, though.  Is there a way to make two
consecutive mouse-face regions not light up at the same time when the
mouse pointer is over a part of one of the regions?

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

bug#39115: 26.3; eww consecutive links look like one link with mouse-over

[Robert Pluim]

>>>>> On Wed, 22 Jan 2020 16:16:05 +0100, Lars Ingebrigtsen <larsi@gnus.org> said:

    Lars> ynyaaa@gmail.com writes:
    >> If two or more links are consecutive without any blank characters,
    >> pointing one of them with mouse activates 'mouse-face of them all at
    >> the same time.

    Lars> Here's a file that demonstrates the problem (open with `M-x eww-open-file'):

    Lars> Hm.GnuFSF


    Lars> I don't know how to fix it, though.  Is there a way to make two
    Lars> consecutive mouse-face regions not light up at the same time when the
    Lars> mouse pointer is over a part of one of the regions?

Add a 'display text property of some kind of arrow/pointer to the end
of each link to achieve visual separation?

Robert

bug#39115: 26.3; eww consecutive links look like one link with mouse-over

[Lars Ingebrigtsen]

Robert Pluim <rpluim@gmail.com> writes:

> Add a 'display text property of some kind of arrow/pointer to the end
> of each link to achieve visual separation?

That sounds annoying if you're copying/yanking the text, doesn't it?

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

bug#39115: 26.3; eww consecutive links look like one link with mouse-over

[Robert Pluim]

>>>>> On Wed, 22 Jan 2020 16:29:22 +0100, Lars Ingebrigtsen <larsi@gnus.org> said:

    Lars> Robert Pluim <rpluim@gmail.com> writes:
    >> Add a 'display text property of some kind of arrow/pointer to the end
    >> of each link to achieve visual separation?

    Lars> That sounds annoying if you're copying/yanking the text, doesn't it?

I thought 'display properties were just displayed, and donʼt
participate in copying/yanking? Am I misinformed?

Robert

bug#39115: 26.3; eww consecutive links look like one link with mouse-over

[Lars Ingebrigtsen]

Robert Pluim <rpluim@gmail.com> writes:

>>>>>> On Wed, 22 Jan 2020 16:29:22 +0100, Lars Ingebrigtsen
> <larsi@gnus.org> said:
>
>     Lars> Robert Pluim <rpluim@gmail.com> writes:
>     >> Add a 'display text property of some kind of arrow/pointer to the end
>     >> of each link to achieve visual separation?
>
>     Lars> That sounds annoying if you're copying/yanking the text, doesn't it?
>
> I thought 'display properties were just displayed, and donʼt
> participate in copying/yanking? Am I misinformed?

I thought you meant that we should put a space char after the link and
put a display property on that -- because the display property has to be
on something.

If the display property is on the entire text, then that would be
awkward, too, and wouldn't help with the issue, I think?  Mousing over
the region would still highlight both links?

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

bug#39115: 26.3; eww consecutive links look like one link with mouse-over

[Robert Pluim]

>>>>> On Wed, 22 Jan 2020 16:45:47 +0100, Lars Ingebrigtsen <larsi@gnus.org> said:

    Lars> Robert Pluim <rpluim@gmail.com> writes:
    >>>>>>> On Wed, 22 Jan 2020 16:29:22 +0100, Lars Ingebrigtsen
    >> <larsi@gnus.org> said:
    >> 
    Lars> Robert Pluim <rpluim@gmail.com> writes:
    >> >> Add a 'display text property of some kind of arrow/pointer to the end
    >> >> of each link to achieve visual separation?
    >> 
    Lars> That sounds annoying if you're copying/yanking the text, doesn't it?
    >> 
    >> I thought 'display properties were just displayed, and donʼt
    >> participate in copying/yanking? Am I misinformed?

    Lars> I thought you meant that we should put a space char after the link and
    Lars> put a display property on that -- because the display property has to be
    Lars> on something.

    Lars> If the display property is on the entire text, then that would be
    Lars> awkward, too, and wouldn't help with the issue, I think?  Mousing over
    Lars> the region would still highlight both links?

Hmm yes, it looks like it (I was thinking of just putting it on the
last character of the link, but I think the effect is the same).

Robert

bug#39115: 26.3; eww consecutive links look like one link with mouse-over

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Wed, 22 Jan 2020 16:16:05 +0100
> Cc: 39115@debbugs.gnu.org
> 
> I don't know how to fix it, though.  Is there a way to make two
> consecutive mouse-face regions not light up at the same time when the
> mouse pointer is over a part of one of the regions?

Not without changes to C-level code, no.  It currently traverses the
glyphs looking for the first one that doesn't have the mouse-face, so
if two stretches of text one after the other have that face, it won't
notice.

If there are brave souls who would like to try their teeth on this,
patches are welcome.  Keep in mind that the relevant code solves the
very non-trivial problem of highlighting reordered bidirectional text,
so any algorithm that needs to rely on buffer positions linearly
increasing with glyph positions on the screen will fail.  The relevant
code is in mouse_face_from_buffer_pos and its subroutine
rows_from_pos_range; see also coords_in_mouse_face_p.

bug#39115: 26.3; eww consecutive links look like one link with mouse-over

[Stephen Berman]

On Wed, 22 Jan 2020 18:31:21 +0200 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Lars Ingebrigtsen <larsi@gnus.org>
>> Date: Wed, 22 Jan 2020 16:16:05 +0100
>> Cc: 39115@debbugs.gnu.org
>>
>> I don't know how to fix it, though.  Is there a way to make two
>> consecutive mouse-face regions not light up at the same time when the
>> mouse pointer is over a part of one of the regions?
>
> Not without changes to C-level code, no.  It currently traverses the
> glyphs looking for the first one that doesn't have the mouse-face, so
> if two stretches of text one after the other have that face, it won't
> notice.

That appears to be so only if the respective face values of the
mouse-face properties have the same name; if the face names are
different, even if one inherits from the other so they are visually
indistinguishable, then each propertized string gets highlighted
independently when the mouse pointer hovers over it, e.g. here:

(insert (propertize "one" 'mouse-face 'highlight)
	(propertize "two" 'mouse-face 'header-line-highlight)
	(propertize "three" 'mouse-face 'highlight) ".")

I don't know if it's easy to make e.g. buttons take advantage of this so
you can have consecutive buttons or links with independent mouse
highlighting.

Steve Berman

bug#39115: 26.3; eww consecutive links look like one link with mouse-over

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>,  ynyaaa@gmail.com,
>   39115@debbugs.gnu.org
> Date: Wed, 22 Jan 2020 20:15:10 +0100
> 
> > Not without changes to C-level code, no.  It currently traverses the
> > glyphs looking for the first one that doesn't have the mouse-face, so
> > if two stretches of text one after the other have that face, it won't
> > notice.
> 
> That appears to be so only if the respective face values of the
> mouse-face properties have the same name; if the face names are
> different, even if one inherits from the other so they are visually
> indistinguishable, then each propertized string gets highlighted
> independently when the mouse pointer hovers over it

That goes without saying, but I thought the request was for the
"normal" mouse face to be able to do that.  It sounds a kludge to me
to ask that each button uses a different value of mouse-face, since it
means someone should construct each button by hand, and not generate
them by generic code.

But if using different face values is a good-enough solution, then
sure, why not.

bug#39115: 26.3; eww consecutive links look like one link with mouse-over

[Stephen Berman]

On Wed, 22 Jan 2020 21:23:40 +0200 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: Lars Ingebrigtsen <larsi@gnus.org>,  ynyaaa@gmail.com,
>>   39115@debbugs.gnu.org
>> Date: Wed, 22 Jan 2020 20:15:10 +0100
>>
>> > Not without changes to C-level code, no.  It currently traverses the
>> > glyphs looking for the first one that doesn't have the mouse-face, so
>> > if two stretches of text one after the other have that face, it won't
>> > notice.
>>
>> That appears to be so only if the respective face values of the
>> mouse-face properties have the same name; if the face names are
>> different, even if one inherits from the other so they are visually
>> indistinguishable, then each propertized string gets highlighted
>> independently when the mouse pointer hovers over it
>
> That goes without saying, but I thought the request was for the
> "normal" mouse face to be able to do that.  It sounds a kludge to me
> to ask that each button uses a different value of mouse-face, since it
> means someone should construct each button by hand, and not generate
> them by generic code.

I also think it would only be worth considering if it could be
programmed.  But for buttons, it seems the problem does not arise: I
just checked insert-button, and it uses overlays, which appear not to
have the adjacency issue that text properties have:

(progn
  (insert-button "one" 'mouse-face 'highlight)
  (insert-button "two" 'mouse-face 'highlight)
  (insert-button "three" 'mouse-face 'highlight))

Why do overlays and text properties differ on this?

Steve Berman

bug#39115: 26.3; eww consecutive links look like one link with mouse-over

[ynyaaa]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> ynyaaa@gmail.com writes:
>
>> If two or more links are consecutive without any blank characters,
>> pointing one of them with mouse activates 'mouse-face of them all at
>> the same time.
>
> Here's a file that demonstrates the problem (open with `M-x eww-open-file'):
>
> Hm.GnuFSF
>
>
> I don't know how to fix it, though.  Is there a way to make two
> consecutive mouse-face regions not light up at the same time when the
> mouse pointer is over a part of one of the regions?

I think it is enough to replace 'mouse-face property from 'highlight
to (list 'highlight).

bug#39115: 26.3; eww consecutive links look like one link with mouse-over

[Lars Ingebrigtsen]

Stephen Berman <stephen.berman@gmx.net> writes:

> I don't know if it's easy to make e.g. buttons take advantage of this so
> you can have consecutive buttons or links with independent mouse
> highlighting.

It would be easy to have to different highlight faces (with the same
properties) and just use them every other time.  But it does seem rather
kludgy...

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

bug#39115: 26.3; eww consecutive links look like one link with mouse-over

[Lars Ingebrigtsen]

ynyaaa@gmail.com writes:

> I think it is enough to replace 'mouse-face property from 'highlight
> to (list 'highlight).

Ah, yes, that works, because the mouse-face is compared with eq.

Does anybody know whether there are any drawbacks to doing this (besides
having an extra cons cell)?  Presumably the display would be slightly
slower, but probably not noticeable.

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

bug#39115: 26.3; eww consecutive links look like one link with mouse-over

[Lars Ingebrigtsen]

Stephen Berman <stephen.berman@gmx.net> writes:

> Why do overlays and text properties differ on this?

Overlays are objects, so even if they have identical properties, it's
easy to see where an overlay starts and stops.  For text properties, we
just use ad-hoc strategies like seeing whether the property we're
interested changes or not, and determine the start/stop of the region
based on that.

It's perhaps unfortunate that text property regions don't have more
"identity", but I guess it'd be difficult to change that now.

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

bug#39115: 26.3; eww consecutive links look like one link with mouse-over

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Thu, 23 Jan 2020 13:18:04 +0100
> Cc: 39115@debbugs.gnu.org
> 
> ynyaaa@gmail.com writes:
> 
> > I think it is enough to replace 'mouse-face property from 'highlight
> > to (list 'highlight).
> 
> Ah, yes, that works, because the mouse-face is compared with eq.
> 
> Does anybody know whether there are any drawbacks to doing this (besides
> having an extra cons cell)?  Presumably the display would be slightly
> slower, but probably not noticeable.

Yes, it will slow down redisplay, so I'm against doing this in core.
Lisp applications which want that can use this kludge, of course.

bug#39115: 26.3; eww consecutive links look like one link with mouse-over

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: larsi@gnus.org,  ynyaaa@gmail.com,  39115@debbugs.gnu.org
> Date: Wed, 22 Jan 2020 21:44:11 +0100
> 
> Why do overlays and text properties differ on this?

That's a side effect of different implementations.  Text properties
are kept as intervals, and so two adjacent intervals with the same
value of the property are indistinguishable from a single interval
covering both stretches of text (and AFAIR we actually convert them
into a single interval when we see fit).  By contrast, overlays are
kept in a list, and you can have any number of them at the same
position with the same property (which is why you can have, e.g., two
or more after-strings at EOB, and they will both be displayed).

bug#39115: 26.3; eww consecutive links look like one link with mouse-over

[Stephen Berman]

On Thu, 23 Jan 2020 13:22:21 +0100 Lars Ingebrigtsen <larsi@gnus.org> wrote:

> Stephen Berman <stephen.berman@gmx.net> writes:
>
>> Why do overlays and text properties differ on this?
>
> Overlays are objects, so even if they have identical properties, it's
> easy to see where an overlay starts and stops.  For text properties, we
> just use ad-hoc strategies like seeing whether the property we're
> interested changes or not, and determine the start/stop of the region
> based on that.
>
> It's perhaps unfortunate that text property regions don't have more
> "identity", but I guess it'd be difficult to change that now.

On Thu, 23 Jan 2020 16:39:46 +0200 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: larsi@gnus.org,  ynyaaa@gmail.com,  39115@debbugs.gnu.org
>> Date: Wed, 22 Jan 2020 21:44:11 +0100
>>
>> Why do overlays and text properties differ on this?
>
> That's a side effect of different implementations.  Text properties
> are kept as intervals, and so two adjacent intervals with the same
> value of the property are indistinguishable from a single interval
> covering both stretches of text (and AFAIR we actually convert them
> into a single interval when we see fit).  By contrast, overlays are
> kept in a list, and you can have any number of them at the same
> position with the same property (which is why you can have, e.g., two
> or more after-strings at EOB, and they will both be displayed).

Thanks for the explanations.

Steve Berman

bug#39115: 26.3; eww consecutive links look like one link with mouse-over

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Yes, it will slow down redisplay, so I'm against doing this in core.
> Lisp applications which want that can use this kludge, of course.

Yeah, I don't see any way for this to be done in core -- it doesn't know
what's considered "the same" region when doing the mouse highlights.

So I'm just doing this in shr.el, and I'm doing it on master, since it
doesn't seem important enough for the release branch.

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

bug#39115: 26.3; eww consecutive links look like one link with mouse-over

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: ynyaaa@gmail.com,  39115@debbugs.gnu.org
> Date: Fri, 24 Jan 2020 16:24:18 +0100
> 
> So I'm just doing this in shr.el, and I'm doing it on master, since it
> doesn't seem important enough for the release branch.

Thanks.  Please be sure to comment this, as I don't think the code
will otherwise explain itself.

bug#39115: 26.3; eww consecutive links look like one link with mouse-over

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> So I'm just doing this in shr.el, and I'm doing it on master, since it
>> doesn't seem important enough for the release branch.
>
> Thanks.  Please be sure to comment this, as I don't think the code
> will otherwise explain itself.

Yeah, the patch was:

-	 'mouse-face 'highlight))
+         ;; Make separate regions not `eq' so that they'll get
+         ;; separate mouse highlights.
+	 'mouse-face (list 'highlight)))


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