From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: =?UTF-8?Q?Cl=C3=A9ment?= Pit-Claudel Newsgroups: gmane.emacs.bugs Subject: bug#4911: mouse-face property should merge face attributes, not replace Date: Sat, 25 Apr 2020 23:10:42 -0400 Message-ID: <35268628-9ef1-8dd2-ab93-05ca1cae06be@gmail.com> References: <8452d0c8-afc3-bdb8-2c88-f66dc770c3c4@gmail.com> <0955d0dd-c4fe-4feb-b68b-0ed212ccf291@default> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="tZIhMJwA6KnpH4Re269jvRlQ6QjqyZJ4r" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="101643"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 Cc: Lars Ingebrigtsen To: Drew Adams , 4911@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Apr 26 05:11:14 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jSXhK-000QId-Ic for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 26 Apr 2020 05:11:14 +0200 Original-Received: from localhost ([::1]:50934 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jSXhJ-0001wm-5m for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 25 Apr 2020 23:11:13 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36418) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jSXh9-0001wY-Q8 for bug-gnu-emacs@gnu.org; Sat, 25 Apr 2020 23:11:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jSXh9-0008Ds-2p for bug-gnu-emacs@gnu.org; Sat, 25 Apr 2020 23:11:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:49111) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jSXh8-0008Dl-LM for bug-gnu-emacs@gnu.org; Sat, 25 Apr 2020 23:11:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jSXh8-0001pG-G2 for bug-gnu-emacs@gnu.org; Sat, 25 Apr 2020 23:11:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?Cl=C3=A9ment?= Pit-Claudel Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 26 Apr 2020 03:11:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 4911 X-GNU-PR-Package: emacs Original-Received: via spool by 4911-submit@debbugs.gnu.org id=B4911.15878706547003 (code B ref 4911); Sun, 26 Apr 2020 03:11:02 +0000 Original-Received: (at 4911) by debbugs.gnu.org; 26 Apr 2020 03:10:54 +0000 Original-Received: from localhost ([127.0.0.1]:60657 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSXgz-0001ot-Mq for submit@debbugs.gnu.org; Sat, 25 Apr 2020 23:10:54 -0400 Original-Received: from mail-qt1-f193.google.com ([209.85.160.193]:34733) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSXgy-0001oh-GA for 4911@debbugs.gnu.org; Sat, 25 Apr 2020 23:10:52 -0400 Original-Received: by mail-qt1-f193.google.com with SMTP id b1so7824078qtt.1 for <4911@debbugs.gnu.org>; Sat, 25 Apr 2020 20:10:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:cc:references:autocrypt:message-id:date:user-agent :mime-version:in-reply-to; bh=gDMtN9v8gkdeON7oAPc8uE+wAlq6hFEY4lydi9djut8=; b=tf0wy501vwX6EQ1NllWUADJ3gCkWjPDENOGuvwXtLQcaPKGhIbLOPd38/nOk37pJbR GRlOIZN45SrcEDs5k8UnrRddnHGOXfFdx9QA+Fr2iM9XVN3id5UTapzwGqSnEV9GKfUl jU929Y9PoCIVfYgvv+zbP1/ZyoUu7dOB+hI8l3lWM4jXB15QhLyWY2n9nIYselVIW3qY 1VNQo6Srqbfv8W8e0ajRFbIE5Bdc6nXt4urH/11hjv8ZGrVHnRCR/TkeKpT43ocnwibg A6LRlyZ5srRYsTnhOiVtT6oz+3fOYzzl48RYfxxJklScO/uJVAbjiOfmCC0AYr17h0j1 cMlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:autocrypt :message-id:date:user-agent:mime-version:in-reply-to; bh=gDMtN9v8gkdeON7oAPc8uE+wAlq6hFEY4lydi9djut8=; b=la+aInZqsplEH2k/XP7QDEbXMuBMg64vATT4fFR1prMUxtKDcEFJ1cXJmSRgsUzBdE TO8qIiy7GLEmPVWjgHdHyDEeCcJ8jOngA4h3qE/SPbgX4ju4fOwcrMgTzbktLXkfSlvX FSwkK9YcCP4nEH8+syDyBy4wsJRTo7th9Bkg/ghzUVPc9rnMvDZFF7G9+YovP+FCXWJh w84ORLRDPUWg96XsMBlcmaJ/20+4eu+M779L15NaGgq5lEWbT9tV/AnGv5kHfGoTi8rP T4a3U3Bea16gJ30hSBLDusY7UygXXSoV+kMTevcsSr5rGA/+mJaSXkcCaAvGmh9n10ld QwBA== X-Gm-Message-State: AGi0PuamJVcb/X98SRtrLhVreEKPfXo6VxtibP6ywmgN2OiYz9nYziq4 OEzcbbs/G7HU3YM+8wKg+1E= X-Google-Smtp-Source: APiQypKCRFAXvdznt5oeDVBKruen7WelrUDElqSDctmK7xDYGQURWVJsHk4EvyFoyFxt6nIf9JffNw== X-Received: by 2002:ac8:1a4d:: with SMTP id q13mr17176808qtk.137.1587870646120; Sat, 25 Apr 2020 20:10:46 -0700 (PDT) Original-Received: from ?IPv6:2601:184:4180:66e7:54d6:bfeb:aa49:9d3b? ([2601:184:4180:66e7:54d6:bfeb:aa49:9d3b]) by smtp.gmail.com with ESMTPSA id j9sm6910059qkk.99.2020.04.25.20.10.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 25 Apr 2020 20:10:45 -0700 (PDT) Autocrypt: addr=clement.pitclaudel@gmail.com; prefer-encrypt=mutual; keydata= xsFNBFStGiEBEAC8eHa+DdcrVtDSwYoIgoUtMfRAan4bdLxZuNIASy6iFytCHNsKqfPkq8zD YV2+uMtbdcnjapE038nidEMItNhO04JdZ+PJ6jvJo1gW+XI4fM8uzkGZauwR+d3hEq6goFSp rIlSlaVf2g5q4OKxI754yqwz00++EZhZQMntzoKQVV9stJ5eQ+gxTT1ANr7wQKbjn/8PM/Cg hBZvYLhh+WsS0Ko5qZuWdsvUBLpprmCWkP4FpZ234/tWpdVID65nlHpu25+6ajIcxfCIK+dN 2br0wN1szTeQFG19cfr3jXEvwHmLQbQqCg4UH+2b7JpMGR2/KWjqRWfWVvZMPVeJdOsZHx53 k6HIbEhvFBHbmqCI6FAZQjkgzGGkrSD92+jeMYiCTxRKqq2hFZ6xqQ6pJdXD1TXcIYPEs7rA MwcNMj8g4e6vuI+2CjHyQQkyMPAEi8guNPnyfBb648f1lxj7JiJu/ehRghIP5u/kLOsHNCKG QgCT04sawBZYHqEVYni8oHlGJcdWGT5/UI4B+wn70eXvYSScZEaB+S2s/bD0cdlSpHY5Od3l tpRZTva+ydswlrz4fxbYF45s6rFpqVwBMfNv3gqhBFXbuiEEctcTSGqhHxxT4R+24Yn+ZSBa EfUbrKnVTUmV20k+57rghiVw2wpj8v7sn3QXt96HJ9ImY4JvuwARAQABzTNDbMOpbWVudCBQ aXQtLUNsYXVkZWwgPGNsZW1lbnQucGl0Y2xhdWRlbEBsaXZlLmNvbT7CwXsEEwECACUCGyMG CwkIBwM In-Reply-To: <0955d0dd-c4fe-4feb-b68b-0ed212ccf291@default> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:179045 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --tZIhMJwA6KnpH4Re269jvRlQ6QjqyZJ4r Content-Type: multipart/mixed; boundary="f8ZF1cvKVyP7aAaQgaDbzVph6ohxcZ1gy"; protected-headers="v1" From: =?UTF-8?Q?Cl=c3=a9ment_Pit-Claudel?= To: Drew Adams , 4911@debbugs.gnu.org Cc: Lars Ingebrigtsen Message-ID: <35268628-9ef1-8dd2-ab93-05ca1cae06be@gmail.com> Subject: Re: mouse-face property should merge face attributes, not replace References: <8452d0c8-afc3-bdb8-2c88-f66dc770c3c4@gmail.com> <0955d0dd-c4fe-4feb-b68b-0ed212ccf291@default> In-Reply-To: <0955d0dd-c4fe-4feb-b68b-0ed212ccf291@default> --f8ZF1cvKVyP7aAaQgaDbzVph6ohxcZ1gy Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Hi Drew, Thanks for your reply! On 25/04/2020 18.13, Drew Adams wrote: >> I hadn't seen Drew's earlier reply when I reopened the bug report, so >> here is a reply to Drew's message: >> >> Drew asked: >>> It's easy enough to move the mouse, to see the non-hover face. =20 >>> Why would one suppose that someone wants to merge that face with >>> `mouse-face'? >> >> There's no need to suppose: users complained. >=20 > What were the complaints, exactly? Users complained that hovering over links was causing syntax highlighting= to disappear. We were hoping to just change the background, or add a li= nk, to the text to indicate that it was clickable, but that caused all of= it to lose its syntax highlighting. >> But to some extent it makes sense, since that's how links behave on th= e >> web (merging faces), so it's hart to fault users for having the same >> expectation in Emacs. >=20 > Really? A mouseover action over a link in a web browser > doesn't change the link appearance, by default. Most websites do, I think (I just checked Google, the New York Times, and= gnu.org), but you're right that the default style sheet doesn't include = a face change.. > But (the equivalent of Emacs) face-merging? How common > is that, really? So common that users expect that? I > don't think I've come across it. I'm not aware of > anything like Emacs face merging. It's always the case: that's how CSS works. Properties applied on hover = stack with properties applied otherwise. To fully replace the underlying face, you would have to make explicit all= attributes of the mouseover face. >>> Just what is the motivation, besides someone feeling the behavior is >>> "ugly"? >> >> The motivation for the original report was that our users were >> complaining to the PG, so it *was* in fact just "'omeone feeling the >> behavior is "ugly"'. >=20 > What's "the PG"? I meant "the PG team", sorry. PG is Proof General. > The one case where I might want something like what > you propose (or maybe exactly like it, depending on > just what it is), would be when mouseover essentially > underlines (or overlines or otherwise doesn't > obscure) the text. In that case, I can see a value > to continuing to show the foreground colors of the > underlined text - if that's realizable. Yes yes yes! We are in violent agreement here :) >> As a concrete example, when I use M-x compile, for example, each error= >> and warning is highlighted. Hovering with the mouse over an error >> removes the highlighting. Why is that helpful? >=20 > It can perhaps be easier to see the extent of the > link? Easier to notice the link? Dunno. With the change of background, it's actually quite readable. > Anyway, I agree that it's helpful to keep face > highlighting is some cases - in particular when, > say, an entire line of code is highlighted. > The effect of, say, `hl-line-mode' is what I > prefer in a case like that - and yes, that's > merging. Similarly, for the region. I think > it's less likely to be useful for links (i.e., > for mouseover). But I could be wrong. Yup, I feel just the same about hl-line-mode and the region. I find the = effect of foreground colors being reset when the background changes due t= o hovering quite distracting, but I agree there's personal taste involved= =2E > It's fine to provide a way (some other way - e.g. > via a variable or another property or whatever) > to have mouseover merge a face instead of imposing > it. Yes, I think all your suggestions are good approaches. >> Also, I noticed that Eli wrote: >> >>> The use case described in the bug >>> report could be handled by using some non-color attribute for the >>> mouse-face, for example. >> >> The original report said that "Users complain that when the mouse is >> over a region the normal fontification is obliterated."; why would it >> help to use a non-color attribute? The normal fontification would >> still be obliterated. >=20 > Maybe Eli meant something like what I suggested above: > adding an underline without changing the foreground > and background colors of the text. Yes, that could > be done by face merging (and yes, currently the normal > fontification gets obliterated). I think that would be great. Maybe I misunderstood: I thought Eli was su= ggesting a workaround that worked with Emacs as it is (which would explai= n why Lars closed the bug), but indeed currently using an underline still= removes other face properties. Thanks again for your input, Cl=C3=A9ment. --f8ZF1cvKVyP7aAaQgaDbzVph6ohxcZ1gy-- --tZIhMJwA6KnpH4Re269jvRlQ6QjqyZJ4r Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEElGa8adIcPra4Jxxu+qD5xOb3TCMFAl6k+7IACgkQ+qD5xOb3 TCOdtRAAqxCVc5pKpWlVdVjS7NxIeAyRZKqBV9Q+VM19fccsARSy2F9fyqW+NqaG G958zyy7Dry/4pZMkfzm+7dKcEerxkhFfAqJE228hUofHzsxA6TYYKIaClTUNHnQ u1fSswd7Mzri6ZuFhHxVHtbj/sJg5AhTIRX4ijOtICH5Lp5i2PhnJczOWqMajrwu G72LSSLYYRxbyv/lyuie2UJTl3tLjoTNXCymdqON3i9zBBFbqaDyq3G+/T2th4Om pNMCrEkljXPWwjHUpLLkMBc7YIO0VueUh2O3588i/UMmC47IA4TATET51WMkuts0 pWS9INMmToKzkpuKvRLk1L62bM+u4XgkFLkawD1pCOoYnDn/XEkOY2p02cfwcit0 KVyCv6fTyZFR2sXtW0N8kwSbGUAmiIUVKrod5bq4Zn3GP8Mm9aeJTFNHMAteNxha gnjKmMD7jCjnyz32RE3T/ed0xY3hK92ZY6NbYY83MX9vxdVcdNtQuCMlmHwiRbX6 Jk5JpV0Ouy7TpUHg1mg3zMYb1Y1fRaPM6fSaw1zy/dPsrAygpn9kQxkVFrSGaE6Q 9UzuZxKIAbSHYmfJhyk1c1nG4btVGgqD2EOE5ksGAsd7DNWdIsbhNe/V/xB1VE4g 7vrQ5c4zMwElS9jeg1DanyI8EI5/wc0+GViuhKIQlKwJQMEnObk= =xQxP -----END PGP SIGNATURE----- --tZIhMJwA6KnpH4Re269jvRlQ6QjqyZJ4r--