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

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

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



Reply | Threaded
Open this post in threaded view
|

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

    Lars> [hidden email] 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



Reply | Threaded
Open this post in threaded view
|

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

Lars Ingebrigtsen
Robert Pluim <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

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

    Lars> Robert Pluim <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

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

Lars Ingebrigtsen
Robert Pluim <[hidden email]> writes:

>>>>>> On Wed, 22 Jan 2020 16:29:22 +0100, Lars Ingebrigtsen
> <[hidden email]> said:
>
>     Lars> Robert Pluim <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
In reply to this post by ynyaaa
> From: Lars Ingebrigtsen <[hidden email]>
> Date: Wed, 22 Jan 2020 16:16:05 +0100
> Cc: [hidden email]
>
> 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.



Reply | Threaded
Open this post in threaded view
|

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

>> From: Lars Ingebrigtsen <[hidden email]>
>> Date: Wed, 22 Jan 2020 16:16:05 +0100
>> Cc: [hidden email]
>>
>> 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



Reply | Threaded
Open this post in threaded view
|

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

>> From: Stephen Berman <[hidden email]>
>> Cc: Lars Ingebrigtsen <[hidden email]>,  [hidden email],
>>   [hidden email]
>> 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



Reply | Threaded
Open this post in threaded view
|

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

Lars Ingebrigtsen
Stephen Berman <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
In reply to this post by Stephen Berman
> From: Stephen Berman <[hidden email]>
> Cc: [hidden email],  [hidden email],  [hidden email]
> 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).



Reply | Threaded
Open this post in threaded view
|

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

Stephen Berman
In reply to this post by Lars Ingebrigtsen
On Thu, 23 Jan 2020 13:22:21 +0100 Lars Ingebrigtsen <[hidden email]> wrote:

> Stephen Berman <[hidden email]> 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 <[hidden email]> wrote:

>> From: Stephen Berman <[hidden email]>
>> Cc: [hidden email],  [hidden email],  [hidden email]
>> 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