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