From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#4911: mouse-face property should merge face attributes, not replace Date: Sat, 25 Apr 2020 15:13:17 -0700 (PDT) Message-ID: <0955d0dd-c4fe-4feb-b68b-0ed212ccf291@default> References: <8452d0c8-afc3-bdb8-2c88-f66dc770c3c4@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="110290"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Lars Ingebrigtsen To: =?UTF-8?Q?Cl=C3=A9ment?= Pit-Claudel , 4911@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Apr 26 00:14:11 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 1jST3q-000Sbu-Bz for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 26 Apr 2020 00:14:10 +0200 Original-Received: from localhost ([::1]:48560 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jST3p-0004BV-0j for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 25 Apr 2020 18:14:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33106) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jST3j-0004BL-BZ for bug-gnu-emacs@gnu.org; Sat, 25 Apr 2020 18:14:03 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jST3i-0002TZ-KE for bug-gnu-emacs@gnu.org; Sat, 25 Apr 2020 18:14:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:48981) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jST3i-0002TT-8G for bug-gnu-emacs@gnu.org; Sat, 25 Apr 2020 18:14:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jST3i-0000U0-3L for bug-gnu-emacs@gnu.org; Sat, 25 Apr 2020 18:14:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 25 Apr 2020 22:14: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.15878528081807 (code B ref 4911); Sat, 25 Apr 2020 22:14:02 +0000 Original-Received: (at 4911) by debbugs.gnu.org; 25 Apr 2020 22:13:28 +0000 Original-Received: from localhost ([127.0.0.1]:60527 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jST3A-0000T4-6b for submit@debbugs.gnu.org; Sat, 25 Apr 2020 18:13:28 -0400 Original-Received: from aserp2120.oracle.com ([141.146.126.78]:41532) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jST37-0000Sr-RZ for 4911@debbugs.gnu.org; Sat, 25 Apr 2020 18:13:27 -0400 Original-Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03PM9dt9173020; Sat, 25 Apr 2020 22:13:20 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2020-01-29; bh=mXLAyOWLUXZZqnPj43Gfkl96AFqL3tWPOe2tjXw1g1Q=; b=py80rHWQy5AdmyXpI2fnfPScsVQmZhrCO81ehh5Of7fHFvqfCsDjFCKMIXP4dmsrutA6 3b3n6CarrukxlIAtKNOylpiM2Ry/p4lTsWDwUIqDBQvBlTA6Oipbybv6MILVQwkLczBo Ou5JYBArPqkHiv/6WACWllsAD/wYnzgfor6IBEK0U6NHnsFs9D0Ii6+pOE7eL+DYIBT2 6pfvKKYZ82HmbvR879+DSq/JIG1ytQIvqCY/F16Z6zfhrUHUQuq/I0zsjzOChM0+dQE2 jY9SzB8fmec7Tt5kmxGCIn6VWVcVNKYH81wWFOlkQVusYuSR9wfeRq3w0PolwjF3aeTE XA== Original-Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by aserp2120.oracle.com with ESMTP id 30md5ksn5r-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 25 Apr 2020 22:13:19 +0000 Original-Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03PM8aC9151534; Sat, 25 Apr 2020 22:13:19 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userp3030.oracle.com with ESMTP id 30maat3t9w-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 25 Apr 2020 22:13:19 +0000 Original-Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 03PMDHjB021903; Sat, 25 Apr 2020 22:13:18 GMT In-Reply-To: <8452d0c8-afc3-bdb8-2c88-f66dc770c3c4@gmail.com> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4993.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9602 signatures=668686 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 phishscore=0 mlxlogscore=999 bulkscore=0 malwarescore=0 suspectscore=0 mlxscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004250194 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9602 signatures=668686 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 mlxscore=0 bulkscore=0 adultscore=0 clxscore=1011 impostorscore=0 priorityscore=1501 phishscore=0 lowpriorityscore=0 mlxlogscore=999 suspectscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004250194 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:179040 Archived-At: > I hadn't seen Drew's earlier reply when I reopened the bug report, so > here is a reply to Drew's message: >=20 > 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'? >=20 > There's no need to suppose: users complained. What were the complaints, exactly? > But to some extent it makes sense, since that's how links behave on the > web (merging faces), so it's hart to fault users for having the same > expectation in Emacs. Really? A mouseover action over a link in a web browser doesn't change the link appearance, by default. Sure, some web pages do different things on a mouseover. Sometimes they replace (what looks like) the face(s) used in the link text with a different face or faces. Sometimes they replace the text itself with different text, or with the same text in a different font (e.g. bigger/smaller). 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. > > Just what is the motivation, besides someone feeling the behavior is > > "ugly"? >=20 > 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"'. What's "the PG"? > I think it would help to understand what the motivation is for erasing > existing faces when applying the mouse face. Drew, what does this > behavior improve for you? My position is that it would be OK to add whatever it is that you're proposing as an option/alternative, but not to just replace the current (longstanding) behavior. My own preference is probably (so far) for a single face on mouseover, for clarity. 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. Probably I'd have to play with it, in practice, to see how much I like it for this or that context. My point is that whether the value of `mouse-face' gets merged with `face' values, or it replaces them, should be under (easy) user and code control. > 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? It can perhaps be easier to see the extent of the link? Easier to notice the link? Dunno. 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. > (Besides, as I wrote in my previous email, merging faces would be > optional, since it would be easy to set a mouse-face to inherit from > 'default and therefore completely remove existing highlighting). Optional is OK by me. But I'm not sure about the mechanism. It should be possible to (optionally) continue to set property `mouse-face' to a face and have that face simply used, not merged with anything. Having both possibilities is better than having only one. 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. One possibility would be to use a different property from `mouse-face', e.g. `merged-mouse-face' or whatever. Another would be, as mentioned, to bind or set a variable that controls whether the value of `mouse-face' gets merged. (The latter gives users more control than the former.) > > And merging could, at least in some cases, make noticing the link > > etc. difficult. >=20 > I didn't understand this part. In which cases would merging the mouse > face with the underlying face *when the mouse is over the link* make > noticing the link harder? When the mouse is over the link, the cursor > typically changes shape; and, while the mouse was not over the link, it > typically had separate highlighting. Why would merging faces when the > mouse is over the link make the link harder to notice? Mentioned above. The visibility of the mouseover change depends on the value of `mouse-face' differing, visually, from the `face' (or `font-lock-face' or ...) property. When a link is on text with different faces, parts of it can become less noticeable on mouseover, depending on text face differences from `mouse-face'. That's already potentially a problem, but I can imagine it being manifested more often with face merging. I think this is the case sometimes for region highlighting, for example.=20 I don't say it's bad - we do that with the region, for example (well, OK, that's an overlay). I just say that I don't think it should systematically _supplant_ the usual (so far) `mouse-face' behavior. > Also, I noticed that Eli wrote: >=20 > > The use case described in the bug > > report could be handled by using some non-color attribute for the > > mouse-face, for example. >=20 > 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. 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).