From daveaspin@googlemail.com Thu Nov 12 04:41:31 2009 Received: (at submit) by emacsbugs.donarmstrong.com; 12 Nov 2009 12:41:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=0.0 required=4.0 tests=none autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id nACCfTUJ002363 for ; Thu, 12 Nov 2009 04:41:30 -0800 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N8YzQ-0008Rd-Hn for bug-gnu-emacs@gnu.org; Thu, 12 Nov 2009 07:41:28 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N8YzK-0008Pm-3X for bug-gnu-emacs@gnu.org; Thu, 12 Nov 2009 07:41:26 -0500 Received: from [199.232.76.173] (port=52389 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N8YzJ-0008Pe-Oe for bug-gnu-emacs@gnu.org; Thu, 12 Nov 2009 07:41:21 -0500 Received: from mail-bw0-f215.google.com ([209.85.218.215]:46975) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N8YzJ-0006rI-8x for bug-gnu-emacs@gnu.org; Thu, 12 Nov 2009 07:41:21 -0500 Received: by bwz7 with SMTP id 7so2197981bwz.26 for ; Thu, 12 Nov 2009 04:41:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=k6T/cjoUCwfkvYexoBrFMq4K4nUY8wuJKkvyVB+Jju4=; b=jgK/ojvaR/UqiTdBy5Mdq1YSXG5lS/PYiITlvsiISF7rJEoT+EVBaaG2qNpX/Mu3WW aAfaLT41tQsFaDx2H/iG7bng0PisBEojysRRRj6o8iY5zi4FaLCam9p2RORzyNjxYRcg NOYhSv7cc7QmS1BBNJZFlL6uS2EkQ1ti8LFso= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=TgkfzZeGjD4kEOVgzentD2S2xfnICKIKmX4Ow+6euxFEhjaWIg6WMlFKP2kdU7gnyZ RnawVH/mVHZjuC1in+5ZCPHyFUFIO7NRmSI8HvsehFqJd8AhtJZbr/VKHnykIY2VWU4F Ipo4Fclppa47RWY1/7ZKxJQKYgluHBcevnUPg= Received: by 10.216.85.133 with SMTP id u5mr1032096wee.91.1258029678732; Thu, 12 Nov 2009 04:41:18 -0800 (PST) Received: from seldon.inf.ed.ac.uk (dhcp-90-125.inf.ed.ac.uk [129.215.90.125]) by mx.google.com with ESMTPS id 5sm222503eyf.0.2009.11.12.04.41.17 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 12 Nov 2009 04:41:17 -0800 (PST) Message-ID: <4AFC026C.4060701@googlemail.com> Date: Thu, 12 Nov 2009 12:41:16 +0000 From: Dave Aspinall User-Agent: Thunderbird 2.0.0.23 (X11/20090825) MIME-Version: 1.0 To: bug-gnu-emacs@gnu.org Subject: mouse-face property should merge face attributes, not replace Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Dear Emacs developers, Perhaps this has been noted already: the low-level behaviour of the mouse-face property seems ugly: it simply overwrites the face property for characters under the mouse. For example in Info, blue underlined links turn black without the underline when the mouse is hovered over them to give the green background from the highlight face. This feels unnatural. In Proof General (http://proofgeneral.inf.ed.ac.uk) we use the mouse-face property on programming language text which is heavily decorated with font-lock. Users complain that when the mouse is over a region the normal fontification is obliterated. - David Aspinall. PS incidentally, we used to prefer XEmacs for Proof General, its display engine did the right thing here. From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 11 01:14:09 2011 Received: (at control) by debbugs.gnu.org; 11 Sep 2011 05:14:09 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R2cMq-00015u-GV for submit@debbugs.gnu.org; Sun, 11 Sep 2011 01:14:08 -0400 Received: from hermes.netfonds.no ([80.91.224.195]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R2cMp-00015o-6e for control@debbugs.gnu.org; Sun, 11 Sep 2011 01:14:07 -0400 Received: from cm-84.215.51.58.getinternet.no ([84.215.51.58] helo=stories.gnus.org) by hermes.netfonds.no with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1R2cId-0002At-J6 for control@debbugs.gnu.org; Sun, 11 Sep 2011 07:09:47 +0200 Date: Sun, 11 Sep 2011 07:06:47 +0200 Message-Id: To: control@debbugs.gnu.org From: Lars Magne Ingebrigtsen Subject: control message for bug #4911 X-MailScanner-ID: 1R2cId-0002At-J6 X-Netfonds-MailScanner: Found to be clean X-Netfonds-MailScanner-From: larsi@gnus.org MailScanner-NULL-Check: 1316322587.67285@Y0w582D6eUCOQM9hxUUiKg X-Spam-Status: No X-Spam-Score: -2.7 (--) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.7 (--) severity 4911 wishlist From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 01 10:08:09 2019 Received: (at 4911) by debbugs.gnu.org; 1 Oct 2019 14:08:09 +0000 Received: from localhost ([127.0.0.1]:34229 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iFIoz-0006RC-3K for submit@debbugs.gnu.org; Tue, 01 Oct 2019 10:08:09 -0400 Received: from quimby.gnus.org ([80.91.231.51]:51966) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iFIow-0006R2-PG for 4911@debbugs.gnu.org; Tue, 01 Oct 2019 10:08:07 -0400 Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=marnie) by quimby.gnus.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iFIos-0003ot-Ni; Tue, 01 Oct 2019 16:08:05 +0200 From: Lars Ingebrigtsen To: Dave Aspinall Subject: Re: bug#4911: mouse-face property should merge face attributes, not replace References: <4AFC026C.4060701@googlemail.com> Date: Tue, 01 Oct 2019 16:08:02 +0200 In-Reply-To: <4AFC026C.4060701@googlemail.com> (Dave Aspinall's message of "Thu, 12 Nov 2009 12:41:16 +0000") Message-ID: <87h84s5zjx.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Dave Aspinall writes: > Perhaps this has been noted already: the low-level behaviour of the > mouse-face property seems ugly: it simply overwrites the face property > for characters under the mouse. For example in Info, bl [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 4911 Cc: 4911@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Dave Aspinall writes: > Perhaps this has been noted already: the low-level behaviour of the > mouse-face property seems ugly: it simply overwrites the face property > for characters under the mouse. For example in Info, blue underlined > links turn black without the underline when the mouse is hovered over > them to give the green background from the highlight face. This feels > unnatural. > > In Proof General (http://proofgeneral.inf.ed.ac.uk) we use the > mouse-face property on programming language text which is heavily > decorated with font-lock. Users complain that when the mouse is over > a region the normal fontification is obliterated. To reproduce: (insert (propertize "hello" 'face 'underline 'mouse-face 'highlight)) and put the mouse pointer over the "hello": The underline goes away. I think it might make sense to merge the properties... but, on the other hand, this may make the text illegible. For instance, this (insert (propertize "hello" 'face '(:foreground "blue") 'mouse-face 'highlight)) would become a blank, blue box if the highlight face didn't define both a foreground colour. So I'm not sure this would work. Any opinions? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 01 10:36:59 2019 Received: (at 4911) by debbugs.gnu.org; 1 Oct 2019 14:36:59 +0000 Received: from localhost ([127.0.0.1]:34272 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iFJGt-0000kD-JW for submit@debbugs.gnu.org; Tue, 01 Oct 2019 10:36:59 -0400 Received: from mail-wr1-f44.google.com ([209.85.221.44]:46324) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iFJGq-0000jy-BQ for 4911@debbugs.gnu.org; Tue, 01 Oct 2019 10:36:57 -0400 Received: by mail-wr1-f44.google.com with SMTP id o18so15804732wrv.13 for <4911@debbugs.gnu.org>; Tue, 01 Oct 2019 07:36:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tcd-ie.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=kZcY2TDsn2hj38Y7xf1CGU+CDe1LVXDGblFFWSyjWgI=; b=1cu5/hZ5MLnWa2CksC34kIPxhlKvEEBY+EUyXrHCk1aNFR/gNqlT4n2b/HVrrFM6Bl 6U900b/naDENktfq6VpioFMxJIRiMrmlcfzurWiuSNsT+GxUOltJEXT5Dhxgv7qc4UXT IWEqCmr7smoT5nypgFvmExuKOwUxa05z601FFMVEyyNqITUA0DOPt9rNKVmWJl5epwGt NVoZphqHMpZ2KoDa/NiMNfsZy7uOpvLXLqjKZRffBUBkGuBXKAWtXiu45nlUKsZZNvhm MMqU7D8FaqBNhoiOpDGLrWcMPubStOaSGa66hHJq1iUUk9yddIEzuhXLtg+94w+azGim XEEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=kZcY2TDsn2hj38Y7xf1CGU+CDe1LVXDGblFFWSyjWgI=; b=Oz2jXZCjdJQ1ssEs8T9GEllZBOXOFRu9XRYz5G4aB+HKmMLrCPna/j/f2W87bNy/os VvwScERNc8ioLvR28R9JI8/M18w2VxNf4XAZcsUZN4kqJfL9tKTBS4Y3PK+tWp/M1Hzo QBlgxQ6EFsg4xPc+fF2pb6f3llxAtdKZc1y6QEokhc19loyW0MwSyMT+1Kew3majf/sx dmIx6JXVIc9N0ITJEimfTRVuY4yzXolgBLIsHGLUBgrLubBWR2+uCDbPV48SZBlU7FVk F/RDsIOb1mg+ajbQShsn1I9kbs8RsxeleHF/h+mSGBNQhx84zNDXECzwtLPWVScHEUFd C9Sg== X-Gm-Message-State: APjAAAW/mYxle1JxdwCkASNq9OL574iC+04dXyXnwn367YR4XcTd692/ ScsjRgUbzcJtaJ3G6iMJVvuJDg== X-Google-Smtp-Source: APXvYqwpFXuqyIDqow3p0L0Khw8GzV+e8DH+3t9GlXV+Q32ZSxhqyzzEMrntf0DziN2Dci6ongGeBA== X-Received: by 2002:a5d:4747:: with SMTP id o7mr2252793wrs.311.1569940610404; Tue, 01 Oct 2019 07:36:50 -0700 (PDT) Received: from localhost ([134.226.214.246]) by smtp.gmail.com with ESMTPSA id e6sm14327209wrp.91.2019.10.01.07.36.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 01 Oct 2019 07:36:49 -0700 (PDT) From: "Basil L. Contovounesios" To: Lars Ingebrigtsen Subject: Re: bug#4911: mouse-face property should merge face attributes, not replace References: <4AFC026C.4060701@googlemail.com> <87h84s5zjx.fsf@gnus.org> Date: Tue, 01 Oct 2019 15:36:44 +0100 In-Reply-To: <87h84s5zjx.fsf@gnus.org> (Lars Ingebrigtsen's message of "Tue, 01 Oct 2019 16:08:02 +0200") Message-ID: <87wodown0j.fsf@tcd.ie> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 4911 Cc: Dave Aspinall , 4911@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Lars Ingebrigtsen writes: > To reproduce: > > (insert (propertize "hello" 'face 'underline 'mouse-face 'highlight)) > > and put the mouse pointer over the "hello": The underline goes away. Isn't this long-standing and documented behaviour? It can be worked around to an extent by defining mouse-face in terms of face: (insert (propertize "hello" 'face 'underline 'mouse-face '(:inherit (highlight underline)))) > I think it might make sense to merge the properties... but, on the > other hand, this may make the text illegible. Indeed, I'm not sure this makes sense in the general case, but I'm no expert. Thanks, -- Basil From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 01 11:00:22 2019 Received: (at 4911) by debbugs.gnu.org; 1 Oct 2019 15:00:22 +0000 Received: from localhost ([127.0.0.1]:34330 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iFJdV-0001d2-OE for submit@debbugs.gnu.org; Tue, 01 Oct 2019 11:00:22 -0400 Received: from eggs.gnu.org ([209.51.188.92]:33061) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iFJdU-0001WZ-FL for 4911@debbugs.gnu.org; Tue, 01 Oct 2019 11:00:20 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:34651) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1iFJdP-0003Df-6f; Tue, 01 Oct 2019 11:00:15 -0400 Received: from [176.228.60.248] (port=1212 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1iFJdO-0000QA-8L; Tue, 01 Oct 2019 11:00:14 -0400 Date: Tue, 01 Oct 2019 18:00:13 +0300 Message-Id: <83d0fga4ua.fsf@gnu.org> From: Eli Zaretskii To: Lars Ingebrigtsen In-reply-to: <87h84s5zjx.fsf@gnus.org> (message from Lars Ingebrigtsen on Tue, 01 Oct 2019 16:08:02 +0200) Subject: Re: bug#4911: mouse-face property should merge face attributes, not replace References: <4AFC026C.4060701@googlemail.com> <87h84s5zjx.fsf@gnus.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 4911 Cc: daveaspin@googlemail.com, 4911@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Date: Tue, 01 Oct 2019 16:08:02 +0200 > Cc: 4911@debbugs.gnu.org > > To reproduce: > > (insert (propertize "hello" 'face 'underline 'mouse-face 'highlight)) > > and put the mouse pointer over the "hello": The underline goes away. > > I think it might make sense to merge the properties... but, on the > other hand, this may make the text illegible. > > For instance, this > > (insert (propertize "hello" 'face '(:foreground "blue") 'mouse-face 'highlight)) > > would become a blank, blue box if the highlight face didn't define both a > foreground colour. > > So I'm not sure this would work. Any opinions? Emacs always worked like that: it selects either 'face' or 'mouse-face', according to what is appropriate, and never merges them. I see no reason to change that now. The use case described in the bug report could be handled by using some non-color attribute for the mouse-face, for example. From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 01 11:14:59 2019 Received: (at 4911) by debbugs.gnu.org; 1 Oct 2019 15:14:59 +0000 Received: from localhost ([127.0.0.1]:34392 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iFJrf-0003qs-Ga for submit@debbugs.gnu.org; Tue, 01 Oct 2019 11:14:59 -0400 Received: from quimby.gnus.org ([80.91.231.51]:53430) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iFJra-0003qb-TL for 4911@debbugs.gnu.org; Tue, 01 Oct 2019 11:14:55 -0400 Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=marnie) by quimby.gnus.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iFJrX-0004VA-Ni; Tue, 01 Oct 2019 17:14:54 +0200 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#4911: mouse-face property should merge face attributes, not replace References: <4AFC026C.4060701@googlemail.com> <87h84s5zjx.fsf@gnus.org> <83d0fga4ua.fsf@gnu.org> Date: Tue, 01 Oct 2019 17:14:51 +0200 In-Reply-To: <83d0fga4ua.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 01 Oct 2019 18:00:13 +0300") Message-ID: <87zhik33bo.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: > I see no reason to change that now. The use case described in the bug > report could be handled by using some non-color attribute for the > mouse-face, for example. Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 4911 Cc: daveaspin@googlemail.com, 4911@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: > I see no reason to change that now. The use case described in the bug > report could be handled by using some non-color attribute for the > mouse-face, for example. Seems like everybody agrees, so I'm closing this bug report. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 01 11:15:08 2019 Received: (at control) by debbugs.gnu.org; 1 Oct 2019 15:15:08 +0000 Received: from localhost ([127.0.0.1]:34397 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iFJrn-0003xH-RX for submit@debbugs.gnu.org; Tue, 01 Oct 2019 11:15:08 -0400 Received: from quimby.gnus.org ([80.91.231.51]:53450) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iFJrl-0003uT-IB for control@debbugs.gnu.org; Tue, 01 Oct 2019 11:15:05 -0400 Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=marnie) by quimby.gnus.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iFJri-0004VM-QQ for control@debbugs.gnu.org; Tue, 01 Oct 2019 17:15:04 +0200 Date: Tue, 01 Oct 2019 17:15:02 +0200 Message-Id: <87y2y433bd.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #4911 X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: close 4911 quit Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) close 4911 quit From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 01 12:46:24 2019 Received: (at 4911) by debbugs.gnu.org; 1 Oct 2019 16:46:24 +0000 Received: from localhost ([127.0.0.1]:34647 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iFLI7-00038d-1H for submit@debbugs.gnu.org; Tue, 01 Oct 2019 12:46:24 -0400 Received: from userp2130.oracle.com ([156.151.31.86]:55330) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iFLI3-00031G-Ev for 4911@debbugs.gnu.org; Tue, 01 Oct 2019 12:46:20 -0400 Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x91GYUqj045525; Tue, 1 Oct 2019 16:46:13 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-2019-08-05; bh=+5GPVt+csBhi5+gVYqZr5W9VW1BE8e/1IPc8lDHyKCM=; b=TBqXgo9bCDT1SlF0lhkzwEHwcMFwlY4nwKR6LCbq3Dy6LtDgIQXSjAfRTzRHbxaZV3he wTLRrNdQR7HHN1NZ6fNEUbDkwExb7tmq19S+6jf/zM9LjpLbZXaIbW5oU+mTm1lhBJ9Z Kw0CN/AtmZN/QWwCC3rNZDTSnmAy5dCyXtugwLC8uEF6R50LzxLd/0SpkA7cxdBRbs0h Lwuic/AXduoadXtS7erQ7Gyg18Rk8oQ7M6u8KFTOhFxw4kOC/2lAubFvWdfHVGa8/1NY OMkAERrwFAQ5vdEABPIJuiExmDVXCZNx8H333nuECKnAuzZC81z871q1UZYI795hpm4d GQ== Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by userp2130.oracle.com with ESMTP id 2v9xxuqe03-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 01 Oct 2019 16:46:13 +0000 Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x91GXPo8001431; Tue, 1 Oct 2019 16:46:12 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserp3020.oracle.com with ESMTP id 2vbqd15xrs-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 01 Oct 2019 16:46:12 +0000 Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id x91GkAGH026685; Tue, 1 Oct 2019 16:46:10 GMT MIME-Version: 1.0 Message-ID: <76cb44c2-3902-4c1c-a706-7cd972d12d96@default> Date: Tue, 1 Oct 2019 09:46:09 -0700 (PDT) From: Drew Adams To: Lars Ingebrigtsen , Dave Aspinall Subject: RE: bug#4911: mouse-face property should merge face attributes, not replace References: <4AFC026C.4060701@googlemail.com> <87h84s5zjx.fsf@gnus.org> In-Reply-To: <87h84s5zjx.fsf@gnus.org> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4900.0 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9397 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1910010141 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9397 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1910010141 X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 4911 Cc: 4911@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > > mouse-face property seems ugly: it simply overwrites the face property > > for characters under the mouse. For example in Info, blue underlined > > links turn black without the underline when the mouse is hovered over > > them to give the green background from the highlight face. This feels > > unnatural. > > > > mouse-face property on programming language text which is heavily > > decorated with font-lock. Users complain that when the mouse is over > > a region the normal fontification is obliterated. FWIW, I don't think it's ugly, and I don't think the underlying (non mouse-face) face attributes show show (be merged). IOW. I'm one user who prefers the current (longstanding) behavior. Just one opinion. > I think it might make sense to merge the properties... but, on the > other hand, this may make the text illegible. Not just less legible. Different (conflicting) purposes. It's easy enough to move the mouse, to see the non-hover face. Why would one suppose that someone wants to merge that face with `mouse-face'? Remember too that `mouse-face' can have any face properties - you are talking about merging arbitrary faces. Just what is the motivation, besides someone feeling the behavior is "ugly"? That font-lock highlighting doesn't show when there's a link (or some other use of `mouse-face') is a feature, not a bug. Why do Proof General users need to see both kinds of highlighting at the same time? And merging could, at least in some cases, make noticing the link etc. difficult. To me, it sounds like Proof General should look for another solution to the problem presented. From unknown Fri Jun 20 07:14:07 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Wed, 30 Oct 2019 11:24:06 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 10 12:06:53 2020 Received: (at control) by debbugs.gnu.org; 10 Apr 2020 16:06:53 +0000 Received: from localhost ([127.0.0.1]:55889 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jMwBB-0002Lx-GN for submit@debbugs.gnu.org; Fri, 10 Apr 2020 12:06:53 -0400 Received: from mail-qt1-f174.google.com ([209.85.160.174]:39890) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jMwB8-0002Lc-Sf for control@debbugs.gnu.org; Fri, 10 Apr 2020 12:06:51 -0400 Received: by mail-qt1-f174.google.com with SMTP id o10so1794618qtr.6 for ; Fri, 10 Apr 2020 09:06:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:message-id:date:user-agent:mime-version:content-language :content-transfer-encoding; bh=mx16441f4okc8nCQfdbfBZZmwglbNJPwLJuIIvp1SaU=; b=NIisCGx8KhV8dsOjyAUX0ZwQ0bwx8AmiSBYRPXziFIboX9LMEVDvcEr4Nppc0L8e0e VvLsJbmdswe8C9fCocDh4GHNACzraL2TZiQdOU9xc2OnPMw7CSuGOM36zYDcwsad7vj/ cnYOFlvEBvoytxiYbLyBr/laCKUiNcZth6om+NOrwvjlH9Tv3H8hph87lkWlrmABxV7u KB5v5OxNTKvkOZgOJYxgxVeVEwZL+TUATC1OTq8zgjFTBnTe860cIGDvNz3sCxxM5bjG olTcaao7iXCrRw8fcRBkbTuaqt/Faa/jiKU4aIkA+AkY/fZ3oSzGLWg75Feo66pgTXrH nFzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=mx16441f4okc8nCQfdbfBZZmwglbNJPwLJuIIvp1SaU=; b=gJACeVZQAKpkqP2IY+cimRWFxizATqUv2gIdW3vqTUI/xUhR1aNzF4AZDDaAApf6u0 ThGGRCBJ1vdCyIyB7nRHqh+9R4OPMNy6aTzkJErjdudAVyxjF+R8gxnGK75urCAX9tDD aq/OFm9YqhGsivzHkfxLYAk6iyxrl1HugWN/B/xPN7FPXuHB/bL85HbRJUDxDT4tXn3h qD8SVUZ319JSD5Y/NIZRZ5N4Vknzwbu3qMiKKWUtFnJf4IobfWoGOyx5/qzN9D5qV9nM AqGFJat6ALUIwlyIFIccKCGRpso21Hr/HNzqC96OUAldVNj8b/D+F0ugaH3roe4x7hKJ FLIA== X-Gm-Message-State: AGi0PuZCzTGihuvQy7IDoFJ2wEcMZWm9sZw96Gc393Hd7WpGlic4/Ekv SDwAbf809dPZwxeDwL1nGwdRpeHL X-Google-Smtp-Source: APiQypLMMED1LtDnk8kcqLa/6VKjDatlYtvvY+oImeVaimNp7K8QtBgWor7dlYrDF+hTNh2AfKLr5w== X-Received: by 2002:ac8:2a68:: with SMTP id l37mr5015637qtl.77.1586534805182; Fri, 10 Apr 2020 09:06:45 -0700 (PDT) Received: from ?IPv6:2601:184:4180:66e7:c45e:9b1f:d618:e435? ([2601:184:4180:66e7:c45e:9b1f:d618:e435]) by smtp.googlemail.com with ESMTPSA id o22sm1748962qtr.50.2020.04.10.09.06.44 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 10 Apr 2020 09:06:44 -0700 (PDT) To: control@debbugs.gnu.org From: =?UTF-8?Q?Cl=c3=a9ment_Pit-Claudel?= Message-ID: Date: Fri, 10 Apr 2020 12:06:42 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Spam-Score: 2.0 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: unarchive 4911 Content analysis details: (2.0 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (cpitclaudel[at]gmail.com) -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.160.174 listed in list.dnswl.org] 0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [209.85.160.174 listed in wl.mailspike.net] 0.0 RCVD_IN_MSPIKE_WL Mailspike good senders 1.8 MISSING_SUBJECT Missing Subject: header 0.2 NO_SUBJECT Extra score for no subject X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) unarchive 4911 From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 10 12:26:21 2020 Received: (at 4911) by debbugs.gnu.org; 10 Apr 2020 16:26:21 +0000 Received: from localhost ([127.0.0.1]:55937 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jMwU0-0004uL-VC for submit@debbugs.gnu.org; Fri, 10 Apr 2020 12:26:21 -0400 Received: from mail-qt1-f173.google.com ([209.85.160.173]:42999) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jMwTz-0004u5-AI for 4911@debbugs.gnu.org; Fri, 10 Apr 2020 12:26:19 -0400 Received: by mail-qt1-f173.google.com with SMTP id b10so1825276qtt.9 for <4911@debbugs.gnu.org>; Fri, 10 Apr 2020 09:26:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=ietsFT48ltmh/EgLduOrc4NL0oDeGwHJwlciNo0CAF8=; b=IeyKdRDwp06fb9fv8fLnemnqXevvWYE7bZLK0g1Y0uZCAePGnfa1okKJTzP6c0dUB6 aRqdtJ2XWM0iYl4A+jwVB6OPzvr4WPJlpRSjorVgJe4hYeFw7YFiTMn0q9EsevEQR+SQ eZmmOvnd0ng2MYx+gTtbNWZPw6ezDF2HPv3tk4rOYRV+S4AtcxHSwUY93ZfyOZ9CiJx3 Hx/KRYCUWMxp3D9TSN6B1zmNrYr95w+TwV22arJ+kmqiVnAQiJtahqDH2ulB1xx+CfwK snrPBMI9+F2fOiXSxu5P1wkXZfrI3mg0z67Y6a/gWXjIByS6ZTN2uHvOTMwxQDcIFfrc ixEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=ietsFT48ltmh/EgLduOrc4NL0oDeGwHJwlciNo0CAF8=; b=hy3hkWcYOrEPEbG1xzq5CGz49SaYgj2PKQ/n051fcdEtYEJEEzvnDGXTYOXovMrEfi D1CdZ8QmWL2mshOK/PGFy1VSdN0WA7tsKrSUfoYw8yZQo44VAsHHeLI9cN3zs/8YqHAK PCS3vbX/qia9o77pRdANxvkUce/+1OV2kjZ6pvs8d294C6hNeROINUvdgkVLhAsQ874r CTV4wpMiKvbnXvpSnVzw+yZPKvtKf6sUSuKFAFLQAltZFJ9aSeRCizi9982s0w70WsAa +BI5C6cBjyrsxBiH7a8mJTduaG4GctGpICqY6SOUku6q7knjU7CBpdE9nybl6O6oEmzn Ulwg== X-Gm-Message-State: AGi0PuaNd6BJcZkaj9s1V2otdVEPUla+B8qFx8NCafRKeoi8BIg7lrbu n2l034HSNO85XiCcpp0uSJR6V/SM X-Google-Smtp-Source: APiQypI1Y/ej6ogsMUGNTx8SgfISmMU88b5om0PY7aRN9inJMNsunjTExbcl0KZ1TnbBxYkAcdZ08A== X-Received: by 2002:ac8:7397:: with SMTP id t23mr2500qtp.196.1586535973529; Fri, 10 Apr 2020 09:26:13 -0700 (PDT) Received: from ?IPv6:2601:184:4180:66e7:c45e:9b1f:d618:e435? ([2601:184:4180:66e7:c45e:9b1f:d618:e435]) by smtp.googlemail.com with ESMTPSA id x65sm1902041qkd.78.2020.04.10.09.26.12 for <4911@debbugs.gnu.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 10 Apr 2020 09:26:13 -0700 (PDT) To: 4911@debbugs.gnu.org From: =?UTF-8?Q?Cl=c3=a9ment_Pit-Claudel?= Subject: mouse-face property should merge face attributes, not replace Message-ID: Date: Fri, 10 Apr 2020 12:26:12 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 4911 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Lars Ingebrigtsen gnus.org> writes: > Eli Zaretskii gnu.org> writes: > >> I see no reason to change that now. The use case described in the bug >> report could be handled by using some non-color attribute for the >> mouse-face, for example. > > Seems like everybody agrees, so I'm closing this bug report. I'd like to disagree :) This is a problem I've run into in various packages and as a user, and the workaround doesn't work when there are multiple different faces applied to the text of a link. As a concrete example, consider compilation-mode, which uses different colors for the file name, the line number, the column number, and the error message. Currently, when hovering over a compilation-mode line highlights it, but also causes it to lose all of its other highlighting. Setting different mouse-face properties to match the different faces would cause the mouse-face highlighting to be only applied to part of the line. Of course, one way to go is to handle mouse-in and mouse-out events in Lisp, creating and removing overlays as needed. But that's explicitly recommended against in the ELisp manual, and it's a lot of work for not much gain. It would be great to have an option for this; maybe as an extra text property, like 'mouse-face-merge? Or maybe as a user option? Of course, if the default changed to merging, recovering the current behavior would be easy even without an extra property (it would just be a matter of making the mouse-face inherit from 'default), I think. But even without changing the default it would be nice to introduce a way to achieve that behavior. Clément. From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 25 18:13:28 2020 Received: (at 4911) by debbugs.gnu.org; 25 Apr 2020 22:13:28 +0000 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 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 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== 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 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 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 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 MIME-Version: 1.0 Message-ID: <0955d0dd-c4fe-4feb-b68b-0ed212ccf291@default> Date: Sat, 25 Apr 2020 15:13:17 -0700 (PDT) From: Drew Adams To: =?utf-8?B?Q2zDqW1lbnQgUGl0LUNsYXVkZWw=?= , 4911@debbugs.gnu.org Subject: RE: mouse-face property should merge face attributes, not replace References: <8452d0c8-afc3-bdb8-2c88-f66dc770c3c4@gmail.com> 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)] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 4911 Cc: Lars Ingebrigtsen X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > 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). From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 25 19:40:52 2020 Received: (at 4911) by debbugs.gnu.org; 25 Apr 2020 23:40:52 +0000 Received: from localhost ([127.0.0.1]:60562 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSUPj-0004rn-4B for submit@debbugs.gnu.org; Sat, 25 Apr 2020 19:40:52 -0400 Received: from mail-qk1-f174.google.com ([209.85.222.174]:41809) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSSGF-0007hb-6Z for 4911@debbugs.gnu.org; Sat, 25 Apr 2020 17:22:55 -0400 Received: by mail-qk1-f174.google.com with SMTP id n143so14139490qkn.8 for <4911@debbugs.gnu.org>; Sat, 25 Apr 2020 14:22:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:cc:autocrypt:subject:message-id:date:user-agent :mime-version:in-reply-to; bh=HC/B0bVkpcJBNfrdIwufZjZRIB5IYLUacsL6nt7DSmM=; b=Vn63GopncJAvFvvcHgSsU42B1TZ1kp0f5uJpvkgKFZrEj7o5ZPCYPDP/e+7RWb1hQR nNIgWjPQRx5aLLn3ljiUee/xoHziUj4w6T6BRVZbyIzB6vblfC/BjQmUaSagAPlfk2OU 9RhQlqjUFlOITmDd5peQ8f+mxT77M3S/ZVO1TEjcBJL/zoaUo8GJKzIDZychvOZ0IDso zOWLMklFItwclnn1bhBKt6EVJBVQgBtDEYCpGBIdXoTkJHu/enMSjhS3u7Y0wh6jjpkl 2cn+Ys5A9Z4kygsmChDEJp+8DvBJ4+lvJX7JeWsmGM3J643+4UmrR6XyqljpKEPxq0v4 e1tA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:cc:autocrypt:subject :message-id:date:user-agent:mime-version:in-reply-to; bh=HC/B0bVkpcJBNfrdIwufZjZRIB5IYLUacsL6nt7DSmM=; b=IKwAu/t3SiY4yvvjiPj7IKgPzjPfny/uOITEjpDTQDZWewyjLNV6DZqkeBJocUX6M3 /ECY7ENmf58dDR/gebZywCQ2Tuk2sj8MS0k0Sfr1eo+oGgAzRoI7yq6iSP7/P6TtAZd1 mTHnnc5L9tdjqVDR/cGlSmvb6eSwAZXwfWu04T5hP8TvGtWeqFyIRrIzLcDO7f25oAn/ VSkKJ0rvkd9N5CnEg5RnRBdZgaQ06yVF2MTK1xEtqcYchxAdvDmV+a6itDIrFolQKssa aPhKh5xZkm7Hfeap2FBqfl/zt/ReagpsMvPuYnia3ra6jUOQ1xpacxPDDeuoCLGEoU10 BWag== X-Gm-Message-State: AGi0PuYzZyjAYgg8HWGtDN+nt9q4RvJswE/n0o/Z2jCN33lPzsHMa3GJ 0Dd0HOifVoeCxrDYWq84LlY= X-Google-Smtp-Source: APiQypJQWNwUrWm1xNNNtAfNDOsZBlAx1vw5eTBNER26EY8VbX4vo0sovwLGtLkYSbhC0yySBg8GNw== X-Received: by 2002:ae9:f507:: with SMTP id o7mr14891790qkg.262.1587849769245; Sat, 25 Apr 2020 14:22:49 -0700 (PDT) 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 m7sm6476018qke.124.2020.04.25.14.22.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 25 Apr 2020 14:22:48 -0700 (PDT) From: =?UTF-8?Q?Cl=c3=a9ment_Pit-Claudel?= To: 4911@debbugs.gnu.org References: 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 CwkIBwMCBhUIAgkKCwQWAgMBAh4BAheABQJUrRuVAhkBAAoJEPqg+cTm90wjResP/j6A9F81 5C78IKzYdYIa7dHNWi4djRdUd79iIHGeFrao6qf7NX3XZmWkpgWExeanaqS7MmJjyXYEh6La JnzojETK+LVYk2xOanKQch2QrxGZVsXFtp/h102J1yTkUKp4g3uyaVlMLDg1P4eHSJC2YHr2 GtE4HTMUW6SThZ1nJQTrSrVpxTL9hRU/O4VIycogD9++zQ3Y1KzGq5xEi+UbjmcycR0dhSSD vAqo3yU46rfgyKPT99JR0edvYAbJaw5uq35Y0y0L6/gV4Bj6c69TADeyc5iTvagPLUWfeWUv YS2M+j7EWRePRmkuBw1ZPxKlibhsfzZBtIt6jEFd+U8ES5ycm6LSqu3ryGlFuFvdrkWzO7Fp SsHo03r6jtc8nY2jnOzsuxVvakMW1JqAiIP2H57Xyv1gZWb60dJDy2k9M7SCONdFLSU6E3k1 ZjyVkWD2cDhoLV2jy11U9hxQt+OfH2M/f+1cZe5Fberz4ceQ0ssLdfOo4dcGd+MW1lixXYj/ VrZj+QmqOdpzjxyLlzd94Mj7cvNzn/bJV4af6fgY+zbGHj8POrIVrIVO0B2/lSLG2HqO+srI 38gpz8vsVuqtuA5QSPT58H3PeAn0uYetCYNammoPRbQadgQOa8z2Bns2c2HsDj4baMck8d+h PDf7MdiEAW7zE6pxQtdr0xo6EREczsFNBFStGiEBEADTKhFNyVXInTxg1rioBtixWbNr2yRt Wu+jR4ECvPW1rY2ThYQ/I2Z97irnhmFnuepIM/gGviXN2OG1+xSBGjJVN4i9chnhxTLHKc+d uqq01tD/OGItoH63MQekOPhsymUyd95Ci01nM18pTzZDghYal47Ex/j+rlM8AaBmtSbTNGN/ rTFGUMvregVqrnnrYfs/LlooxHtTAbpY19e/sZX5b9EWdsa6k074bt6ew3TQ9xm7/4grV06H vc1b0I79Rk8vPslXh9Wh6qS4+OLkvFWnwTUachInxlD4E0wdK33XaaSxarFSmnYcVrsW2Izy gPoRMYgB5oUPtmUE8F/WfhWZ0Z3P9cKXx3EP6Z25PN3UJFXr+kZpVow65bx0MFIu/N5ygbHX sQ482CQwgzg5rr3arxXB9AknHC753jSJeld1oAsy1J+hmY7iSGxjoZeL4Yoq8IINNeq1QbH0 vo9esK4hmUi2fXIg/GKoramWJ6DjiObuHOJvXkiV9QS7GVnlHq1Z2/HGN998n6nmUj7i70lk a1XiJ3LFtAcxqsnjc1hXdi2yuOnbHRhpVBIuCEsj3EKtp5zTVkAK77c5LOIIRoij9ACUaT6x D6r93jbuw5HbSHP3aW3P/jkQ3kgZXPaa6890kPe3eRqyf9iOYpcAWu71TSqQldaOZ1Nl2Ttk 1JY8UQARAQABwsFfBBgBAgAJBQJUrRohAhsMAAoJEPqg+cTm90wjqucP/3di/s4HIltDHvte Css8JYINdfkdfkt5ub75YLoBa5blPIMJ/E5HMiQ90dAnIlg0ZQ39AOJ0agyg7vNSi199Y1Kn 3TSpAAiTo5V8ry8CuyqJ+0t4czr5PUr6P+8ggFAXMSn5NbZPQHZRods3GFtO5pq/6gwWxBiO 6VcLEqeEdz+ZzusISIPtuz56biaeR5+lh3FVITvXzVHY/7mXeKKb/HKy4gwHmNnWAqrELjg1 vtTtJJnPyrTUE6vYzO1pfNs7ynfcylV5q6oloLNwChQweMfFtDHOiOv6wweLav43+28WAElD Saw618yT8fFSWYGl9tUmADoRgHfFrcHrcZ0v/27C4Gh/bbESUJqm4ik1wZPrEjIwSZJFAm5k 2wTlRMnuxT7cGZVYChG2awk5wbYqofwivGcpY1X+HSGivYXEGQmvPSdONFbgr1FUDXKgcsbw qsxaBtx407fDL8ohnWnsjqB0X6sWUjllm8Afxabwr2WCzdRut6/HIXcrFHIFjzHokIqartiO 0J0tmANHEACjmDgF6E1XlUi0SnNXDV0Us2z4843kEocj8Z6zFNQkuMy0ArQbuxVG0i5jaRaA nI6nLB+ouU4UJNUnzrVnVr2sQuruMIIb9u7DVTodwfkrEVw0aoiSW3D7CTATZcBihOo8NZjm hze1s8uad9n9PQF+gigV Subject: Re: mouse-face property should merge face attributes, not replace Message-ID: <8452d0c8-afc3-bdb8-2c88-f66dc770c3c4@gmail.com> Date: Sat, 25 Apr 2020 17:22:46 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="zzpkaufEHasfNCebSRYIrYbl7jecRH7rC" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 4911 X-Mailman-Approved-At: Sat, 25 Apr 2020 19:40:50 -0400 Cc: Lars Ingebrigtsen , Drew Adams X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --zzpkaufEHasfNCebSRYIrYbl7jecRH7rC Content-Type: multipart/mixed; boundary="S8RSlkW2hP7ScOtjnwGowelH7hC1YhHsj"; protected-headers="v1" From: =?UTF-8?Q?Cl=c3=a9ment_Pit-Claudel?= To: 4911@debbugs.gnu.org Cc: Drew Adams , Lars Ingebrigtsen Message-ID: <8452d0c8-afc3-bdb8-2c88-f66dc770c3c4@gmail.com> Subject: Re: mouse-face property should merge face attributes, not replace References: In-Reply-To: --S8RSlkW2hP7ScOtjnwGowelH7hC1YhHsj Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable I hadn't seen Drew's earlier reply when I reopened the bug report, so her= e is a reply to Drew's message: Drew asked: > Why would one suppose that someone wants to merge that face with=20 > `mouse-face'? There's no need to suppose: users complained. But to some extent it makes sense, since that's how links behave on the w= eb (merging faces), so it's hart to fault users for having the same expec= tation in Emacs. > Just what is the motivation, besides someone feeling the behavior is=20 > "ugly"? The motivation for the original report was that our users were complainin= g to the PG, so it *was* in fact just "'omeone feeling the behavior is "u= gly"'. I think it would help to understand what the motivation is for erasing ex= isting faces when applying the mouse face. Drew, what does this behavior= improve for you? As a concrete example, when I use M-x compile, for example, each error an= d warning is highlighted. Hovering with the mouse over an error removes = the highlighting. Why is that helpful? (Besides, as I wrote in my previous email, merging faces would be optiona= l, since it would be easy to set a mouse-face to inherit from 'default an= d therefore completely remove existing highlighting). > And merging could, at least in some cases, make noticing the link=20 > etc. difficult. I didn't understand this part. In which cases would merging the mouse fa= ce with the underlying face *when the mouse is over the link* make notici= ng the link harder? When the mouse is over the link, the cursor typicall= y changes shape; and, while the mouse was not over the link, it typically= had separate highlighting. Why would merging faces when the mouse is ov= er the link make the link harder to notice? 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 obli= terated. Cheers, Cl=C3=A9ment. On 10/04/2020 12.26, Cl=C3=A9ment Pit-Claudel wrote: > Lars Ingebrigtsen gnus.org> writes: >> Eli Zaretskii gnu.org> writes: >> >>> I see no reason to change that now. The use case described in the bu= g >>> report could be handled by using some non-color attribute for the >>> mouse-face, for example. >> >> Seems like everybody agrees, so I'm closing this bug report. >=20 > I'd like to disagree :) This is a problem I've run into in various pack= ages and as a user, and the workaround doesn't work when there are multip= le different faces applied to the text of a link. >=20 > As a concrete example, consider compilation-mode, which uses different = colors for the file name, the line number, the column number, and the err= or message. Currently, when hovering over a compilation-mode line highli= ghts it, but also causes it to lose all of its other highlighting. >=20 > Setting different mouse-face properties to match the different faces wo= uld cause the mouse-face highlighting to be only applied to part of the l= ine. >=20 > Of course, one way to go is to handle mouse-in and mouse-out events in = Lisp, creating and removing overlays as needed. But that's explicitly re= commended against in the ELisp manual, and it's a lot of work for not muc= h gain. >=20 > It would be great to have an option for this; maybe as an extra text pr= operty, like 'mouse-face-merge? Or maybe as a user option? > Of course, if the default changed to merging, recovering the current be= havior would be easy even without an extra property (it would just be a m= atter of making the mouse-face inherit from 'default), I think. But even= without changing the default it would be nice to introduce a way to achi= eve that behavior. >=20 > Cl=C3=A9ment. >=20 --S8RSlkW2hP7ScOtjnwGowelH7hC1YhHsj-- --zzpkaufEHasfNCebSRYIrYbl7jecRH7rC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEElGa8adIcPra4Jxxu+qD5xOb3TCMFAl6kqiYACgkQ+qD5xOb3 TCOsUA//Uce8fPMEkMuxhsYz3FY3gFSenq+Ivp63pUa5bnAfKtf37rMYhOqVdP0z v2kc4UMgyhR9oQXgeUwKzRB+ln9M3KgXqOK3Ehg6D1rnKGCbQjqmWbBHC1DBhvU9 ud8c69k39Z7YIGl26jeK7WJKiPmfQo4/7954ZQ2xYS7kUwtrNMZiEnBN0yHsupEE GAHfYuKBSyX8qeDCRaoSdYW5zmpOEv7BnFgKHLL+WHIdq63jtvM9RCuxX6PEBQ9D j+/vvDJ+1P8mHGRz+0HejWxtRD6ZCy9ei2bRnXCGLvuPVhUQFkYOIH++EjZAAO1L X6WgCBoqsdatMiM9jWOy7hOb6iKg5IjOdm8JpxzeiCOopXB/p50sWWlokManIW4V qa/EvdCFSfVlc698/E2o97HahfFr552WhFX2aaWxXh/V0Z1n+khu/HgFWVfTY+EO pF8r56gEjWDu75DGbU/nlLTgc/N1UdmfD6J9qkmBEfLZUeagSN4P9+ecvK7UUeco 464lFqjlJhXGx7IUkghQbhL9N921iqbqPj5/bvkKLzMN7WmAXJuYDqnf9RWDhWyT 3t/BJheEaxwmob3MubWWzq7TFXrB9ht5wchjfAzpL/kDcR7tVN78JbrbxvNtNptA 79D0nLR8KAEMJK9xWWP1G80qLP5ctN9PEEbcmOOtEcaMGhinc0k= =zNE/ -----END PGP SIGNATURE----- --zzpkaufEHasfNCebSRYIrYbl7jecRH7rC-- From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 25 23:10:54 2020 Received: (at 4911) by debbugs.gnu.org; 26 Apr 2020 03:10:54 +0000 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 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 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) 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) From: =?UTF-8?Q?Cl=c3=a9ment_Pit-Claudel?= Subject: Re: mouse-face property should merge face attributes, not replace To: Drew Adams , 4911@debbugs.gnu.org References: <8452d0c8-afc3-bdb8-2c88-f66dc770c3c4@gmail.com> <0955d0dd-c4fe-4feb-b68b-0ed212ccf291@default> 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 CwkIBwMCBhUIAgkKCwQWAgMBAh4BAheABQJUrRuVAhkBAAoJEPqg+cTm90wjResP/j6A9F81 5C78IKzYdYIa7dHNWi4djRdUd79iIHGeFrao6qf7NX3XZmWkpgWExeanaqS7MmJjyXYEh6La JnzojETK+LVYk2xOanKQch2QrxGZVsXFtp/h102J1yTkUKp4g3uyaVlMLDg1P4eHSJC2YHr2 GtE4HTMUW6SThZ1nJQTrSrVpxTL9hRU/O4VIycogD9++zQ3Y1KzGq5xEi+UbjmcycR0dhSSD vAqo3yU46rfgyKPT99JR0edvYAbJaw5uq35Y0y0L6/gV4Bj6c69TADeyc5iTvagPLUWfeWUv YS2M+j7EWRePRmkuBw1ZPxKlibhsfzZBtIt6jEFd+U8ES5ycm6LSqu3ryGlFuFvdrkWzO7Fp SsHo03r6jtc8nY2jnOzsuxVvakMW1JqAiIP2H57Xyv1gZWb60dJDy2k9M7SCONdFLSU6E3k1 ZjyVkWD2cDhoLV2jy11U9hxQt+OfH2M/f+1cZe5Fberz4ceQ0ssLdfOo4dcGd+MW1lixXYj/ VrZj+QmqOdpzjxyLlzd94Mj7cvNzn/bJV4af6fgY+zbGHj8POrIVrIVO0B2/lSLG2HqO+srI 38gpz8vsVuqtuA5QSPT58H3PeAn0uYetCYNammoPRbQadgQOa8z2Bns2c2HsDj4baMck8d+h PDf7MdiEAW7zE6pxQtdr0xo6EREczsFNBFStGiEBEADTKhFNyVXInTxg1rioBtixWbNr2yRt Wu+jR4ECvPW1rY2ThYQ/I2Z97irnhmFnuepIM/gGviXN2OG1+xSBGjJVN4i9chnhxTLHKc+d uqq01tD/OGItoH63MQekOPhsymUyd95Ci01nM18pTzZDghYal47Ex/j+rlM8AaBmtSbTNGN/ rTFGUMvregVqrnnrYfs/LlooxHtTAbpY19e/sZX5b9EWdsa6k074bt6ew3TQ9xm7/4grV06H vc1b0I79Rk8vPslXh9Wh6qS4+OLkvFWnwTUachInxlD4E0wdK33XaaSxarFSmnYcVrsW2Izy gPoRMYgB5oUPtmUE8F/WfhWZ0Z3P9cKXx3EP6Z25PN3UJFXr+kZpVow65bx0MFIu/N5ygbHX sQ482CQwgzg5rr3arxXB9AknHC753jSJeld1oAsy1J+hmY7iSGxjoZeL4Yoq8IINNeq1QbH0 vo9esK4hmUi2fXIg/GKoramWJ6DjiObuHOJvXkiV9QS7GVnlHq1Z2/HGN998n6nmUj7i70lk a1XiJ3LFtAcxqsnjc1hXdi2yuOnbHRhpVBIuCEsj3EKtp5zTVkAK77c5LOIIRoij9ACUaT6x D6r93jbuw5HbSHP3aW3P/jkQ3kgZXPaa6890kPe3eRqyf9iOYpcAWu71TSqQldaOZ1Nl2Ttk 1JY8UQARAQABwsFfBBgBAgAJBQJUrRohAhsMAAoJEPqg+cTm90wjqucP/3di/s4HIltDHvte Css8JYINdfkdfkt5ub75YLoBa5blPIMJ/E5HMiQ90dAnIlg0ZQ39AOJ0agyg7vNSi199Y1Kn 3TSpAAiTo5V8ry8CuyqJ+0t4czr5PUr6P+8ggFAXMSn5NbZPQHZRods3GFtO5pq/6gwWxBiO 6VcLEqeEdz+ZzusISIPtuz56biaeR5+lh3FVITvXzVHY/7mXeKKb/HKy4gwHmNnWAqrELjg1 vtTtJJnPyrTUE6vYzO1pfNs7ynfcylV5q6oloLNwChQweMfFtDHOiOv6wweLav43+28WAElD Saw618yT8fFSWYGl9tUmADoRgHfFrcHrcZ0v/27C4Gh/bbESUJqm4ik1wZPrEjIwSZJFAm5k 2wTlRMnuxT7cGZVYChG2awk5wbYqofwivGcpY1X+HSGivYXEGQmvPSdONFbgr1FUDXKgcsbw qsxaBtx407fDL8ohnWnsjqB0X6sWUjllm8Afxabwr2WCzdRut6/HIXcrFHIFjzHokIqartiO 0J0tmANHEACjmDgF6E1XlUi0SnNXDV0Us2z4843kEocj8Z6zFNQkuMy0ArQbuxVG0i5jaRaA nI6nLB+ouU4UJNUnzrVnVr2sQuruMIIb9u7DVTodwfkrEVw0aoiSW3D7CTATZcBihOo8NZjm hze1s8uad9n9PQF+gigV Message-ID: <35268628-9ef1-8dd2-ab93-05ca1cae06be@gmail.com> Date: Sat, 25 Apr 2020 23:10:42 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <0955d0dd-c4fe-4feb-b68b-0ed212ccf291@default> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="tZIhMJwA6KnpH4Re269jvRlQ6QjqyZJ4r" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 4911 Cc: Lars Ingebrigtsen X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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-- From debbugs-submit-bounces@debbugs.gnu.org Sun Apr 26 09:34:27 2020 Received: (at 4911) by debbugs.gnu.org; 26 Apr 2020 13:34:27 +0000 Received: from localhost ([127.0.0.1]:32844 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jShQR-00052M-CK for submit@debbugs.gnu.org; Sun, 26 Apr 2020 09:34:27 -0400 Received: from eggs.gnu.org ([209.51.188.92]:43666) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jShQP-000524-Ko for 4911@debbugs.gnu.org; Sun, 26 Apr 2020 09:34:26 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:43241) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jShQK-0000aR-37; Sun, 26 Apr 2020 09:34:20 -0400 Received: from [176.228.60.248] (port=1785 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jShQJ-0002ya-IF; Sun, 26 Apr 2020 09:34:19 -0400 Date: Sun, 26 Apr 2020 16:34:11 +0300 Message-Id: <83blne74mk.fsf@gnu.org> From: Eli Zaretskii To: =?utf-8?Q?Cl=C3=A9ment?= Pit-Claudel In-Reply-To: <35268628-9ef1-8dd2-ab93-05ca1cae06be@gmail.com> (message from =?utf-8?Q?Cl=C3=A9ment?= Pit-Claudel on Sat, 25 Apr 2020 23:10:42 -0400) Subject: Re: bug#4911: mouse-face property should merge face attributes, not replace References: <8452d0c8-afc3-bdb8-2c88-f66dc770c3c4@gmail.com> <0955d0dd-c4fe-4feb-b68b-0ed212ccf291@default> <35268628-9ef1-8dd2-ab93-05ca1cae06be@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 4911 Cc: larsi@gnus.org, 4911@debbugs.gnu.org, drew.adams@oracle.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Clément Pit-Claudel > Date: Sat, 25 Apr 2020 23:10:42 -0400 > Cc: Lars Ingebrigtsen > > > 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 suggesting a workaround that worked with Emacs as it is (which would explain why Lars closed the bug), but indeed currently using an underline still removes other face properties. No, this cannot be done with the current display code, and I'm sorry I posted a confusing suggestion. If someone wants to work on an option whereby we will merge the mouse face with the face of each highlighted character, that would be welcome. I just want to warn volunteers that providing such a feature is not going to be simple: the way mouse-highlight is currently implemented we simply redraw a stretch of glyphs on the screen with a face that is already "realized" and cached (see xfaces.c). Which means face merging has been already done, and we can only use the existing faces which were merged long ago. Making this new feature happen would then require reimplementing mouse-highlight similar to the region (some kind of overlay), and I hope the result will not cause annoying flicker, since in principle we will have to trigger redisplay on each mouse move, unlike a much simpler redraw we do now. From debbugs-submit-bounces@debbugs.gnu.org Sun Apr 26 13:24:19 2020 Received: (at 4911) by debbugs.gnu.org; 26 Apr 2020 17:24:20 +0000 Received: from localhost ([127.0.0.1]:34819 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSl0t-0006P2-Jn for submit@debbugs.gnu.org; Sun, 26 Apr 2020 13:24:19 -0400 Received: from userp2130.oracle.com ([156.151.31.86]:50408) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSl0r-0006Op-PO for 4911@debbugs.gnu.org; Sun, 26 Apr 2020 13:24:18 -0400 Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03QHN1IO173276; Sun, 26 Apr 2020 17:24:11 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=cy5gEnU9mtjUASEyXQpuCrMFQ8ih7f1Rw5H4cJatfYA=; b=yklTsjtqNkI9T8XeZlp0L6cjW11gwcwEMSBX5tdDIbSerEwS4qTIeJuHl45eN+Etm/6V Gw4fWOckSNR8pq1qXLLAuvaDiTXmTk0r0J8xl/rNPORlXqH9bpZuWNebG0TibdxdDrhg BmBlLn5pFWRRIZZg6+uN+BNPhLDiBLT7SUFp/5BcFGP9ZZk1hXyli6mlHXdlW+9OgHed 9ZjK5xMg34ngNDIHzdl9fg/fWeRIQwplyzDLF5AtHxb8euMHJ2QHVeBNhyMEKzXmX2O+ nMVd6yPXKGUQnxoo+kxtTFNmIow7mLBKar9hWGD+xiKBNuZWTiaXSpBUu4txKmNUA6yl cg== Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by userp2130.oracle.com with ESMTP id 30mcmquegp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 26 Apr 2020 17:24:11 +0000 Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03QHLqNL003102; Sun, 26 Apr 2020 17:22:11 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserp3030.oracle.com with ESMTP id 30mxrnys0a-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 26 Apr 2020 17:22:11 +0000 Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 03QHMAIF007042; Sun, 26 Apr 2020 17:22:10 GMT MIME-Version: 1.0 Message-ID: Date: Sun, 26 Apr 2020 10:22:09 -0700 (PDT) From: Drew Adams To: =?utf-8?B?Q2zDqW1lbnQgUGl0LUNsYXVkZWw=?= , 4911@debbugs.gnu.org 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> <35268628-9ef1-8dd2-ab93-05ca1cae06be@gmail.com> In-Reply-To: <35268628-9ef1-8dd2-ab93-05ca1cae06be@gmail.com> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4993.0 (x86)] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9603 signatures=668686 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 phishscore=0 suspectscore=0 mlxlogscore=999 malwarescore=0 bulkscore=0 spamscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004260158 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9603 signatures=668686 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 spamscore=0 clxscore=1015 priorityscore=1501 suspectscore=0 impostorscore=0 adultscore=0 malwarescore=0 bulkscore=0 lowpriorityscore=0 mlxlogscore=999 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004260158 X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 4911 Cc: Lars Ingebrigtsen X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > >> 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. >=20 > 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.. I don't think I see that on nytimes.com or google.com. I do see a mouseover "face" change on both, on inline links in text, but what I see is all or nothing. For NYT, for example, a link is shown underlined, and mouseover removes the underline - IOW, two different "faces", and mouseover uses the same face for all of the link text. I don't see examples of link text that has (the equivalent of) multiple faces, so I can't see what happens with mouseover on such links. Do you have an example of a link on some such site, where the link text uses multiple "faces" and mouseover preserves those faces while perhaps adding or removing some "face attributes" across all of them? > > 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. >=20 > Yes yes yes! We are in violent agreement here :) I thought so. But probably "more or less", and not violently. ;-) > > > Why is that helpful? > > > > It can perhaps be easier to see the extent of the > > link? Easier to notice the link? Dunno. >=20 > With the change of background, it's actually quite readable. I think it can depend on the background, and how it interacts with the default/frame face and with the faces used in the link text. You may be right that in general most mouseover backgrounds would not be problematic; 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. >=20 > 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 to hovering quite distracting, but I agree there's personal taste > involved. The question is really about links (mouseover). > > 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. >=20 > Yes, I think all your suggestions are good approaches. It would be good to try a patch, in some context where there is already lots of use of different faces. One such context is the use of font-lock faces, but in most such uses there isn't much predefined use of links. > Thanks again for your input, And thank you for the suggestion/bug report, and attention to providing the new feature only as an option/alternative. (BTW, why doesn't the bug # appear in the subject line?) From debbugs-submit-bounces@debbugs.gnu.org Mon May 04 11:16:15 2020 Received: (at 4911) by debbugs.gnu.org; 4 May 2020 15:16:15 +0000 Received: from localhost ([127.0.0.1]:33718 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jVcpL-0002ZY-6K for submit@debbugs.gnu.org; Mon, 04 May 2020 11:16:15 -0400 Received: from mail-qt1-f171.google.com ([209.85.160.171]:38122) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jVcpJ-0002ZL-LU for 4911@debbugs.gnu.org; Mon, 04 May 2020 11:16:14 -0400 Received: by mail-qt1-f171.google.com with SMTP id i68so14265929qtb.5 for <4911@debbugs.gnu.org>; Mon, 04 May 2020 08:16:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:cc:references:from:autocrypt:subject:message-id:date:user-agent :mime-version:in-reply-to; bh=8tKA3y6xuAkT9SgAYr+kFnaruNaxvGIl2gDlErhaMdM=; b=j67FbLLGnuvtRWGcg2vvym21j6u9l6LIIteW5hdO8IwhpZ39d2hip4QEyxX7Fwe8Vi P6KnuchfYW9C/pgXaibPdTMnTxWbmTpFk5LftpnlmHX4QgqOwq7Ch6D5X5YNGq+RhnuQ JdTuI4+MEaQweF8f6QMqt7+itmEkhNWbBSLqIqMoGj23J+ZQaxIMtmqN9pG5yMk2ktZz g+eZ+wQpMVsq7HRoU/jrIe9dU6BwHwrBhNoPE6MKdOJw5ZsCddmev7CAPW7k5VW2Zgkk c+D3opVCeJ6F6hpmTBD8vgqWWkT442rYnwFxpSvUpZCqa3f6x9Ezxf4D9EMQ0cz2S4wu f3zA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:references:from:autocrypt:subject :message-id:date:user-agent:mime-version:in-reply-to; bh=8tKA3y6xuAkT9SgAYr+kFnaruNaxvGIl2gDlErhaMdM=; b=DzJA7aRRp/n5ftZ2aUdyHzOvp0rQKdZjvNXsFfLGK4eaYe2GIEuPHsiTg9xDKD/qdv qaDRsEmWJpS6Uuskh4f7zuuMtpdmPxyYV939XyqE/FOB/sNqt+tNSbcIkp9UaJun+IJR B1Fb8cft2bhfrCGjym7w/Z+ph+WlU/qQHKeHpUzMlXHXh/6d0tgbDlzs0PaL7QLgKEVL dGcpt8mmfMTYnpX+Uq2ibtTh7Flh9DStqXprNw2ZR9YmBlu5ubRlXpFP/mMmBwGoXNyV wpruuQZaGI0rX4FUXATh+JOVWCMnnY2HBPvCr5UfCeE23yBiVHQfuFsrPZbJMe7YS14o v56Q== X-Gm-Message-State: AGi0PuafO/DWIUPLtXwuKRZDiTVgiimnsE9/cqMhMzVO8SUGMZMpxcaO 4IZJvkXxMyD0cbwSBPQtBLc= X-Google-Smtp-Source: APiQypKHRLHnq07kHzkwQqfE6jyDl0rlymt736t2zrXH9EnXmcF0V75a6Und99U3ikjArUdbm2nKcg== X-Received: by 2002:ac8:70c:: with SMTP id g12mr17035353qth.71.1588605367993; Mon, 04 May 2020 08:16:07 -0700 (PDT) Received: from ?IPv6:2601:184:4180:66e7:4837:46bf:979:6a47? ([2601:184:4180:66e7:4837:46bf:979:6a47]) by smtp.gmail.com with ESMTPSA id g187sm9938944qkf.115.2020.05.04.08.16.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 04 May 2020 08:16:06 -0700 (PDT) To: Eli Zaretskii References: <8452d0c8-afc3-bdb8-2c88-f66dc770c3c4@gmail.com> <0955d0dd-c4fe-4feb-b68b-0ed212ccf291@default> <35268628-9ef1-8dd2-ab93-05ca1cae06be@gmail.com> <83blne74mk.fsf@gnu.org> From: =?UTF-8?Q?Cl=c3=a9ment_Pit-Claudel?= 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 CwkIBwMCBhUIAgkKCwQWAgMBAh4BAheABQJUrRuVAhkBAAoJEPqg+cTm90wjResP/j6A9F81 5C78IKzYdYIa7dHNWi4djRdUd79iIHGeFrao6qf7NX3XZmWkpgWExeanaqS7MmJjyXYEh6La JnzojETK+LVYk2xOanKQch2QrxGZVsXFtp/h102J1yTkUKp4g3uyaVlMLDg1P4eHSJC2YHr2 GtE4HTMUW6SThZ1nJQTrSrVpxTL9hRU/O4VIycogD9++zQ3Y1KzGq5xEi+UbjmcycR0dhSSD vAqo3yU46rfgyKPT99JR0edvYAbJaw5uq35Y0y0L6/gV4Bj6c69TADeyc5iTvagPLUWfeWUv YS2M+j7EWRePRmkuBw1ZPxKlibhsfzZBtIt6jEFd+U8ES5ycm6LSqu3ryGlFuFvdrkWzO7Fp SsHo03r6jtc8nY2jnOzsuxVvakMW1JqAiIP2H57Xyv1gZWb60dJDy2k9M7SCONdFLSU6E3k1 ZjyVkWD2cDhoLV2jy11U9hxQt+OfH2M/f+1cZe5Fberz4ceQ0ssLdfOo4dcGd+MW1lixXYj/ VrZj+QmqOdpzjxyLlzd94Mj7cvNzn/bJV4af6fgY+zbGHj8POrIVrIVO0B2/lSLG2HqO+srI 38gpz8vsVuqtuA5QSPT58H3PeAn0uYetCYNammoPRbQadgQOa8z2Bns2c2HsDj4baMck8d+h PDf7MdiEAW7zE6pxQtdr0xo6EREczsFNBFStGiEBEADTKhFNyVXInTxg1rioBtixWbNr2yRt Wu+jR4ECvPW1rY2ThYQ/I2Z97irnhmFnuepIM/gGviXN2OG1+xSBGjJVN4i9chnhxTLHKc+d uqq01tD/OGItoH63MQekOPhsymUyd95Ci01nM18pTzZDghYal47Ex/j+rlM8AaBmtSbTNGN/ rTFGUMvregVqrnnrYfs/LlooxHtTAbpY19e/sZX5b9EWdsa6k074bt6ew3TQ9xm7/4grV06H vc1b0I79Rk8vPslXh9Wh6qS4+OLkvFWnwTUachInxlD4E0wdK33XaaSxarFSmnYcVrsW2Izy gPoRMYgB5oUPtmUE8F/WfhWZ0Z3P9cKXx3EP6Z25PN3UJFXr+kZpVow65bx0MFIu/N5ygbHX sQ482CQwgzg5rr3arxXB9AknHC753jSJeld1oAsy1J+hmY7iSGxjoZeL4Yoq8IINNeq1QbH0 vo9esK4hmUi2fXIg/GKoramWJ6DjiObuHOJvXkiV9QS7GVnlHq1Z2/HGN998n6nmUj7i70lk a1XiJ3LFtAcxqsnjc1hXdi2yuOnbHRhpVBIuCEsj3EKtp5zTVkAK77c5LOIIRoij9ACUaT6x D6r93jbuw5HbSHP3aW3P/jkQ3kgZXPaa6890kPe3eRqyf9iOYpcAWu71TSqQldaOZ1Nl2Ttk 1JY8UQARAQABwsFfBBgBAgAJBQJUrRohAhsMAAoJEPqg+cTm90wjqucP/3di/s4HIltDHvte Css8JYINdfkdfkt5ub75YLoBa5blPIMJ/E5HMiQ90dAnIlg0ZQ39AOJ0agyg7vNSi199Y1Kn 3TSpAAiTo5V8ry8CuyqJ+0t4czr5PUr6P+8ggFAXMSn5NbZPQHZRods3GFtO5pq/6gwWxBiO 6VcLEqeEdz+ZzusISIPtuz56biaeR5+lh3FVITvXzVHY/7mXeKKb/HKy4gwHmNnWAqrELjg1 vtTtJJnPyrTUE6vYzO1pfNs7ynfcylV5q6oloLNwChQweMfFtDHOiOv6wweLav43+28WAElD Saw618yT8fFSWYGl9tUmADoRgHfFrcHrcZ0v/27C4Gh/bbESUJqm4ik1wZPrEjIwSZJFAm5k 2wTlRMnuxT7cGZVYChG2awk5wbYqofwivGcpY1X+HSGivYXEGQmvPSdONFbgr1FUDXKgcsbw qsxaBtx407fDL8ohnWnsjqB0X6sWUjllm8Afxabwr2WCzdRut6/HIXcrFHIFjzHokIqartiO 0J0tmANHEACjmDgF6E1XlUi0SnNXDV0Us2z4843kEocj8Z6zFNQkuMy0ArQbuxVG0i5jaRaA nI6nLB+ouU4UJNUnzrVnVr2sQuruMIIb9u7DVTodwfkrEVw0aoiSW3D7CTATZcBihOo8NZjm hze1s8uad9n9PQF+gigV Subject: Re: bug#4911: mouse-face property should merge face attributes, not replace Message-ID: Date: Mon, 4 May 2020 11:16:05 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <83blne74mk.fsf@gnu.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="wRvxBRQGXQxesL8irUG4RLyKazWVOmtCU" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 4911 Cc: larsi@gnus.org, 4911@debbugs.gnu.org, drew.adams@oracle.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wRvxBRQGXQxesL8irUG4RLyKazWVOmtCU Content-Type: multipart/mixed; boundary="NWAkGTzbQv9KcA9YrHH9triXk7Rb4e1kA"; protected-headers="v1" From: =?UTF-8?Q?Cl=c3=a9ment_Pit-Claudel?= To: Eli Zaretskii Cc: drew.adams@oracle.com, 4911@debbugs.gnu.org, larsi@gnus.org Message-ID: Subject: Re: bug#4911: mouse-face property should merge face attributes, not replace References: <8452d0c8-afc3-bdb8-2c88-f66dc770c3c4@gmail.com> <0955d0dd-c4fe-4feb-b68b-0ed212ccf291@default> <35268628-9ef1-8dd2-ab93-05ca1cae06be@gmail.com> <83blne74mk.fsf@gnu.org> In-Reply-To: <83blne74mk.fsf@gnu.org> --NWAkGTzbQv9KcA9YrHH9triXk7Rb4e1kA Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 26/04/2020 09.34, Eli Zaretskii wrote: > If someone wants to work on an option whereby we will merge the mouse > face with the face of each highlighted character, that would be=20 > welcome. I just want to warn volunteers that providing such a=20 > feature is not going to be simple: the way mouse-highlight is=20 > currently implemented we simply redraw a stretch of glyphs on the=20 > screen with a face that is already "realized" and cached (see=20 > xfaces.c). Which means face merging has been already done, and we=20 > can only use the existing faces which were merged long ago. Making=20 > this new feature happen would then require reimplementing=20 > mouse-highlight similar to the region (some kind of overlay) Thanks a lot, this summary was very useful. I've been pondering this issue since your last message, hoping to find a = way to keep the complexity down and not introduce flickering. Currently we cache a single realized mouse_face. Could we cache a sequen= ce of such realized faces instead, attached to regions of text? That is,= we'd compute the realized mouse-face for all regions of the current span= , and cache that. Concretely, I guess this would mean enhancing Mouse_HL= Info to keep a list of spans instead of a single one. Cl=C3=A9ment. --NWAkGTzbQv9KcA9YrHH9triXk7Rb4e1kA-- --wRvxBRQGXQxesL8irUG4RLyKazWVOmtCU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEElGa8adIcPra4Jxxu+qD5xOb3TCMFAl6wMbUACgkQ+qD5xOb3 TCNL6A/9H9d02J7tn0zo2lPVlgtm7Tiyi5A8T25wcDlAaMY0svgfpSFAaAnuSWr6 lE9RFCAjFT8sIx1y+2hSCpV8ZGyMRLpsAjZwMmrBcAw5lB1FhJu0p8JCgk1Ex8xa XRmgNOEzVPRkt9ZRkH4XEaH+3UDIA6qeTFjWtRSkW+XJyEf7nF5+fMkw0ODHRzcT cZlZrSrzPd74AGwYlaO9lgjhzOpDdhnkvGv3s4d+koLDe2yWf29ZyS+ll6qxfE7m OjenHydZvldhcNQ5Yd39/ntvb716vLDr4K1azGzswJqVAHPfr2Y5dEM6jg03VjZW L9YsiNVxyM5cS4piMVQ9rPqHzd45NgT2gDnTD5leNje7uIQlRtJnAAF3E7nVLdUL ZrItIcRPdVLBiLzb910IElVo2ek8XeV4GjaocJLF08WoTO9gkhmw526hxP/BBw3k qxaWsMmscBV1oBAiduCIh5itZ0/WxpK8aZed961KteXqJurwu0WjQFCDz+GKs6TC OzZxEuF+0h872Bk8u3DXSs5D9me5buFZN43eGwpVlglVx8KgLqft61J1Rq7mq8ne /rXINjgRjDHxOM1Ng+EBgiQ2pe+Y9S2KWuPKgRk2PE3P+gLyrsjONzJrxeJc7GV1 p0m8Q1kJeSkYRRhOrnLPZQDvzY0JkafJC3csUoUo33CUHULWoSU= =J/zx -----END PGP SIGNATURE----- --wRvxBRQGXQxesL8irUG4RLyKazWVOmtCU-- From debbugs-submit-bounces@debbugs.gnu.org Fri May 08 10:39:44 2020 Received: (at 4911) by debbugs.gnu.org; 8 May 2020 14:39:44 +0000 Received: from localhost ([127.0.0.1]:46050 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jX4AB-0003Si-RY for submit@debbugs.gnu.org; Fri, 08 May 2020 10:39:44 -0400 Received: from eggs.gnu.org ([209.51.188.92]:49110) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jX4A9-0003SS-Hh for 4911@debbugs.gnu.org; Fri, 08 May 2020 10:39:42 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:58674) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jX4A4-0007i0-6e; Fri, 08 May 2020 10:39:36 -0400 Received: from [176.228.60.248] (port=2339 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jX4A3-00049x-9X; Fri, 08 May 2020 10:39:35 -0400 Date: Fri, 08 May 2020 17:39:22 +0300 Message-Id: <83a72iij8l.fsf@gnu.org> From: Eli Zaretskii To: =?utf-8?Q?Cl=C3=A9ment?= Pit-Claudel In-Reply-To: (message from =?utf-8?Q?Cl=C3=A9ment?= Pit-Claudel on Mon, 4 May 2020 11:16:05 -0400) Subject: Re: bug#4911: mouse-face property should merge face attributes, not replace References: <8452d0c8-afc3-bdb8-2c88-f66dc770c3c4@gmail.com> <0955d0dd-c4fe-4feb-b68b-0ed212ccf291@default> <35268628-9ef1-8dd2-ab93-05ca1cae06be@gmail.com> <83blne74mk.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 4911 Cc: larsi@gnus.org, 4911@debbugs.gnu.org, drew.adams@oracle.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: drew.adams@oracle.com, 4911@debbugs.gnu.org, larsi@gnus.org > From: Clément Pit-Claudel > Date: Mon, 4 May 2020 11:16:05 -0400 > > Currently we cache a single realized mouse_face. Could we cache a sequence of such realized faces instead, attached to regions of text? That is, we'd compute the realized mouse-face for all regions of the current span, and cache that. Concretely, I guess this would mean enhancing Mouse_HLInfo to keep a list of spans instead of a single one. I'm not sure I understand what you mean by "span" in general and "current span" in particular. We could, of course, realize such combinations. It would need: . realizing and caching 2 faces whenever we render some text which has a mouse-face property; . recording the buffer positions to which those realized mouse-faces are relevant; and . using the corresponding face when redrawing the highlighted portions of text by looking at the positions of each of the affected glyphs (which might be complicated if the text doesn't come from a buffer) From debbugs-submit-bounces@debbugs.gnu.org Fri May 08 11:01:46 2020 Received: (at 4911) by debbugs.gnu.org; 8 May 2020 15:01:46 +0000 Received: from localhost ([127.0.0.1]:46080 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jX4VW-00042U-Ev for submit@debbugs.gnu.org; Fri, 08 May 2020 11:01:46 -0400 Received: from mail-qt1-f178.google.com ([209.85.160.178]:43021) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jX4VU-00042D-Ed for 4911@debbugs.gnu.org; Fri, 08 May 2020 11:01:44 -0400 Received: by mail-qt1-f178.google.com with SMTP id z90so1445113qtd.10 for <4911@debbugs.gnu.org>; Fri, 08 May 2020 08:01:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:cc:references:from:autocrypt:subject:message-id:date:user-agent :mime-version:in-reply-to; bh=ARqQS7xCyRvavsMTi7DN6rLwZ0BABSf24Ptloc1jYoI=; b=IejkujoF60jGB/Mqa+NEY0t3S0meO0+Py4/y2bTpQ4ZEr0J6xgY2GWa++16GDTlF/c KRmxajuG7wm/juNfQjOi7hoz5pUZUijI6zHBiJ3YoZNZR/iVhJTXrNRhXo+3qq/+vDzG 6zLjfUW9jcTLYg4C6OHNmOU3B6qlmx7zrcCjWYjB8eE7xPWBLk2yPxQgBAkomKfV4ns/ 3YHIwCU1F+Nx+ms4KEJyKJm5s9Q9V4hBfd4IGggHj/Bamdv+1lLukoLLNPhfKjyiAk7Q pSJh6H3OVrxbTYx82RFRrswLr5PxbkvMroBFUGycIfTZf0A+pZISsM/Ut6EBG2EKne29 tllA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:references:from:autocrypt:subject :message-id:date:user-agent:mime-version:in-reply-to; bh=ARqQS7xCyRvavsMTi7DN6rLwZ0BABSf24Ptloc1jYoI=; b=N4uwpt6ExNFaM/q/a/o+SYrZ1LyRarPWmj626/gfWpr3ado16efBP3cE45A8NvU0oY ByFSBlpLKCjCxfhRhg6jPVUHx/rtbcOKjAwQSyv2c817uroWNf7StHRX3+pnFlLQmSGu kwg8Bde3h4cXB1D0QRPVahVO3YGla1wlG0IrndIba5jkaChryeA1eynepP8EUlK9Z9Jf Djla/Ioequs2pHGf4fj/ZQLbCjArlPxTZ1nR9au+cgiT+VQ38rd4quBJbMKlDWzPdlk3 1MDSr8hvkSnU4oPNOx9aUi0OXpw5LQv1Ox1zdsrO0s1j6Tx5la0L0yrFqW7up3TNNfCv 3FWQ== X-Gm-Message-State: AGi0Puaf+7Je3MxMorSPXRyQ6g32wXzQyvDPrJ/g9b8UM0LivzFWBBaw HtXuENciVH7Ohs2ItjsPC2c= X-Google-Smtp-Source: APiQypLgrNzzHi7BVzCxl6Apz5GQPB75OHdXe7V79epywvporAtcoftjsRXKLX0I8X8L4gjie9RT7w== X-Received: by 2002:ac8:4796:: with SMTP id k22mr3395102qtq.215.1588950098383; Fri, 08 May 2020 08:01:38 -0700 (PDT) Received: from ?IPv6:2601:184:4180:66e7:4d17:b25e:8d9:2188? ([2601:184:4180:66e7:4d17:b25e:8d9:2188]) by smtp.gmail.com with ESMTPSA id e206sm1315692qkb.94.2020.05.08.08.01.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 08 May 2020 08:01:37 -0700 (PDT) To: Eli Zaretskii References: <8452d0c8-afc3-bdb8-2c88-f66dc770c3c4@gmail.com> <0955d0dd-c4fe-4feb-b68b-0ed212ccf291@default> <35268628-9ef1-8dd2-ab93-05ca1cae06be@gmail.com> <83blne74mk.fsf@gnu.org> <83a72iij8l.fsf@gnu.org> From: =?UTF-8?Q?Cl=c3=a9ment_Pit-Claudel?= 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 CwkIBwMCBhUIAgkKCwQWAgMBAh4BAheABQJUrRuVAhkBAAoJEPqg+cTm90wjResP/j6A9F81 5C78IKzYdYIa7dHNWi4djRdUd79iIHGeFrao6qf7NX3XZmWkpgWExeanaqS7MmJjyXYEh6La JnzojETK+LVYk2xOanKQch2QrxGZVsXFtp/h102J1yTkUKp4g3uyaVlMLDg1P4eHSJC2YHr2 GtE4HTMUW6SThZ1nJQTrSrVpxTL9hRU/O4VIycogD9++zQ3Y1KzGq5xEi+UbjmcycR0dhSSD vAqo3yU46rfgyKPT99JR0edvYAbJaw5uq35Y0y0L6/gV4Bj6c69TADeyc5iTvagPLUWfeWUv YS2M+j7EWRePRmkuBw1ZPxKlibhsfzZBtIt6jEFd+U8ES5ycm6LSqu3ryGlFuFvdrkWzO7Fp SsHo03r6jtc8nY2jnOzsuxVvakMW1JqAiIP2H57Xyv1gZWb60dJDy2k9M7SCONdFLSU6E3k1 ZjyVkWD2cDhoLV2jy11U9hxQt+OfH2M/f+1cZe5Fberz4ceQ0ssLdfOo4dcGd+MW1lixXYj/ VrZj+QmqOdpzjxyLlzd94Mj7cvNzn/bJV4af6fgY+zbGHj8POrIVrIVO0B2/lSLG2HqO+srI 38gpz8vsVuqtuA5QSPT58H3PeAn0uYetCYNammoPRbQadgQOa8z2Bns2c2HsDj4baMck8d+h PDf7MdiEAW7zE6pxQtdr0xo6EREczsFNBFStGiEBEADTKhFNyVXInTxg1rioBtixWbNr2yRt Wu+jR4ECvPW1rY2ThYQ/I2Z97irnhmFnuepIM/gGviXN2OG1+xSBGjJVN4i9chnhxTLHKc+d uqq01tD/OGItoH63MQekOPhsymUyd95Ci01nM18pTzZDghYal47Ex/j+rlM8AaBmtSbTNGN/ rTFGUMvregVqrnnrYfs/LlooxHtTAbpY19e/sZX5b9EWdsa6k074bt6ew3TQ9xm7/4grV06H vc1b0I79Rk8vPslXh9Wh6qS4+OLkvFWnwTUachInxlD4E0wdK33XaaSxarFSmnYcVrsW2Izy gPoRMYgB5oUPtmUE8F/WfhWZ0Z3P9cKXx3EP6Z25PN3UJFXr+kZpVow65bx0MFIu/N5ygbHX sQ482CQwgzg5rr3arxXB9AknHC753jSJeld1oAsy1J+hmY7iSGxjoZeL4Yoq8IINNeq1QbH0 vo9esK4hmUi2fXIg/GKoramWJ6DjiObuHOJvXkiV9QS7GVnlHq1Z2/HGN998n6nmUj7i70lk a1XiJ3LFtAcxqsnjc1hXdi2yuOnbHRhpVBIuCEsj3EKtp5zTVkAK77c5LOIIRoij9ACUaT6x D6r93jbuw5HbSHP3aW3P/jkQ3kgZXPaa6890kPe3eRqyf9iOYpcAWu71TSqQldaOZ1Nl2Ttk 1JY8UQARAQABwsFfBBgBAgAJBQJUrRohAhsMAAoJEPqg+cTm90wjqucP/3di/s4HIltDHvte Css8JYINdfkdfkt5ub75YLoBa5blPIMJ/E5HMiQ90dAnIlg0ZQ39AOJ0agyg7vNSi199Y1Kn 3TSpAAiTo5V8ry8CuyqJ+0t4czr5PUr6P+8ggFAXMSn5NbZPQHZRods3GFtO5pq/6gwWxBiO 6VcLEqeEdz+ZzusISIPtuz56biaeR5+lh3FVITvXzVHY/7mXeKKb/HKy4gwHmNnWAqrELjg1 vtTtJJnPyrTUE6vYzO1pfNs7ynfcylV5q6oloLNwChQweMfFtDHOiOv6wweLav43+28WAElD Saw618yT8fFSWYGl9tUmADoRgHfFrcHrcZ0v/27C4Gh/bbESUJqm4ik1wZPrEjIwSZJFAm5k 2wTlRMnuxT7cGZVYChG2awk5wbYqofwivGcpY1X+HSGivYXEGQmvPSdONFbgr1FUDXKgcsbw qsxaBtx407fDL8ohnWnsjqB0X6sWUjllm8Afxabwr2WCzdRut6/HIXcrFHIFjzHokIqartiO 0J0tmANHEACjmDgF6E1XlUi0SnNXDV0Us2z4843kEocj8Z6zFNQkuMy0ArQbuxVG0i5jaRaA nI6nLB+ouU4UJNUnzrVnVr2sQuruMIIb9u7DVTodwfkrEVw0aoiSW3D7CTATZcBihOo8NZjm hze1s8uad9n9PQF+gigV Subject: Re: bug#4911: mouse-face property should merge face attributes, not replace Message-ID: <38d17eb2-ba5b-30a6-d9ac-ec18ee7d8fe9@gmail.com> Date: Fri, 8 May 2020 11:01:35 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <83a72iij8l.fsf@gnu.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="DoSeGQJ46vOG8qwARh81HBXWJn9hvXQkD" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 4911 Cc: larsi@gnus.org, 4911@debbugs.gnu.org, drew.adams@oracle.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --DoSeGQJ46vOG8qwARh81HBXWJn9hvXQkD Content-Type: multipart/mixed; boundary="RPcWroiE2EbHaLNIYbLIYRWw4gsncOKeh"; protected-headers="v1" From: =?UTF-8?Q?Cl=c3=a9ment_Pit-Claudel?= To: Eli Zaretskii Cc: drew.adams@oracle.com, 4911@debbugs.gnu.org, larsi@gnus.org Message-ID: <38d17eb2-ba5b-30a6-d9ac-ec18ee7d8fe9@gmail.com> Subject: Re: bug#4911: mouse-face property should merge face attributes, not replace References: <8452d0c8-afc3-bdb8-2c88-f66dc770c3c4@gmail.com> <0955d0dd-c4fe-4feb-b68b-0ed212ccf291@default> <35268628-9ef1-8dd2-ab93-05ca1cae06be@gmail.com> <83blne74mk.fsf@gnu.org> <83a72iij8l.fsf@gnu.org> In-Reply-To: <83a72iij8l.fsf@gnu.org> --RPcWroiE2EbHaLNIYbLIYRWw4gsncOKeh Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 08/05/2020 10.39, Eli Zaretskii wrote: >> Cc: drew.adams@oracle.com, 4911@debbugs.gnu.org, larsi@gnus.org >> From: Cl=C3=A9ment Pit-Claudel >> Date: Mon, 4 May 2020 11:16:05 -0400 >> >> Currently we cache a single realized mouse_face. Could we cache a seq= uence of such realized faces instead, attached to regions of text? That = is, we'd compute the realized mouse-face for all regions of the current s= pan, and cache that. Concretely, I guess this would mean enhancing Mouse= _HLInfo to keep a list of spans instead of a single one. >=20 > I'm not sure I understand what you mean by "span" in general and > "current span" in particular. I meant a range of text with a single mouse-face property. > We could, of course, realize such combinations. It would need: >=20 > . realizing and caching 2 faces whenever we render some text which > has a mouse-face property; Don't we already do this, currently? > . recording the buffer positions to which those realized mouse-faces > are relevant; and That makes sense. Basically, I was hoping to change Mouse_HLInfo to cont= ain more than one range and more than one face. > . using the corresponding face when redrawing the highlighted > portions of text by looking at the positions of each of the > affected glyphs (which might be complicated if the text doesn't > come from a buffer) But isn't that already taken care of by the existing highlighting code? --RPcWroiE2EbHaLNIYbLIYRWw4gsncOKeh-- --DoSeGQJ46vOG8qwARh81HBXWJn9hvXQkD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEElGa8adIcPra4Jxxu+qD5xOb3TCMFAl61dE8ACgkQ+qD5xOb3 TCPwsxAAi7OJrQIb6+H5F4t2Pt9LRSpDHhkjnzQOG1E5RmTBAOQNu+5U50AHp6Qe r005UHsYNurI98EqMhlJbPOj3sHjXV0kVLBkyXUFTpCTJFa7rA10JfKI14OSN1oB zBe5dcCCD0ue4WnNIm4Y933z7mX/Bk4VyP3W8gzdPbdn+Bbee4Ay9k8AR1oGEZ8X xUa22BSpjdBKuV29psaCu5rR059PVTwGeiPpS47dBk6k/1ZI5pu4W5nmb0YVTD7h JJNF1ufK7VtKXkneHpB5+ZZhJXKjntHx7INR5ACp6T8DDDDSXheEwg/s2ZIDF6Oc 71U5AaMZ1iDLfmX1DvyGBqA4JlyQfF5u27drZkTj3MuBYHmUAh07MUfQsHdWOthz +F3pNgYl/FeM7ha2RbvsN9mOb86ZiIEm7HyWJ8KA746ZonYbS0KaP0PxYJ2DK4Qa pBp8PQmqig4zkQRkVnuTePL8GVS/TgFRAjv7b3JTpQUiuGSRHsfbf2f1NCX5MTS9 zQohpN37Culnf4aVTGBuZvjdptr+BMHrfsBQon8bea8bk5zLLcMsoYwBG8KbvQwM g2Dxa44kX1tLsQBZnPLm60c/JC9O8tSkD7/Bqo2KjZTPRFNvSTIVKk8IDjlc+YTK 8bi5U0FJEqoPFmOFy+bAxyQxIa9te9PTfcGn+jDZ0PRMutp/AFg= =hi79 -----END PGP SIGNATURE----- --DoSeGQJ46vOG8qwARh81HBXWJn9hvXQkD-- From debbugs-submit-bounces@debbugs.gnu.org Fri May 08 11:20:41 2020 Received: (at 4911) by debbugs.gnu.org; 8 May 2020 15:20:42 +0000 Received: from localhost ([127.0.0.1]:46112 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jX4np-0004We-I6 for submit@debbugs.gnu.org; Fri, 08 May 2020 11:20:41 -0400 Received: from eggs.gnu.org ([209.51.188.92]:59626) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jX4no-0004WS-6b for 4911@debbugs.gnu.org; Fri, 08 May 2020 11:20:40 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:59383) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jX4ng-0003r6-Ud; Fri, 08 May 2020 11:20:33 -0400 Received: from [176.228.60.248] (port=4887 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jX4ng-0001n4-D8; Fri, 08 May 2020 11:20:32 -0400 Date: Fri, 08 May 2020 18:20:20 +0300 Message-Id: <83368aihcb.fsf@gnu.org> From: Eli Zaretskii To: =?utf-8?Q?Cl=C3=A9ment?= Pit-Claudel In-Reply-To: <38d17eb2-ba5b-30a6-d9ac-ec18ee7d8fe9@gmail.com> (message from =?utf-8?Q?Cl=C3=A9ment?= Pit-Claudel on Fri, 8 May 2020 11:01:35 -0400) Subject: Re: bug#4911: mouse-face property should merge face attributes, not replace References: <8452d0c8-afc3-bdb8-2c88-f66dc770c3c4@gmail.com> <0955d0dd-c4fe-4feb-b68b-0ed212ccf291@default> <35268628-9ef1-8dd2-ab93-05ca1cae06be@gmail.com> <83blne74mk.fsf@gnu.org> <83a72iij8l.fsf@gnu.org> <38d17eb2-ba5b-30a6-d9ac-ec18ee7d8fe9@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 4911 Cc: larsi@gnus.org, 4911@debbugs.gnu.org, drew.adams@oracle.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: drew.adams@oracle.com, 4911@debbugs.gnu.org, larsi@gnus.org > From: Clément Pit-Claudel > Date: Fri, 8 May 2020 11:01:35 -0400 > > > I'm not sure I understand what you mean by "span" in general and > > "current span" in particular. > > I meant a range of text with a single mouse-face property. But if the underlying text has different face properties, the range of text should now be divided into different "spans", no? > > . realizing and caching 2 faces whenever we render some text which > > has a mouse-face property; > > Don't we already do this, currently? No, because we only have a single mouse-face. With this feature, we'd have multiple ones, and they are only known when the face of the text is being realized, because each character could have different sources of face information, which need to be merged. > > . recording the buffer positions to which those realized mouse-faces > > are relevant; and > > That makes sense. Basically, I was hoping to change Mouse_HLInfo to contain more than one range and more than one face. Maybe that, too, will have to be used. > > . using the corresponding face when redrawing the highlighted > > portions of text by looking at the positions of each of the > > affected glyphs (which might be complicated if the text doesn't > > come from a buffer) > > But isn't that already taken care of by the existing highlighting code? No, because the existing code always uses the same mouse-face. So it only needs to know which glyphs need to be redrawn with that single face. From debbugs-submit-bounces@debbugs.gnu.org Fri May 08 11:58:33 2020 Received: (at 4911) by debbugs.gnu.org; 8 May 2020 15:58:33 +0000 Received: from localhost ([127.0.0.1]:46171 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jX5OK-0005Ub-Ij for submit@debbugs.gnu.org; Fri, 08 May 2020 11:58:33 -0400 Received: from mail-qk1-f170.google.com ([209.85.222.170]:44196) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jX5OI-0005UP-GS for 4911@debbugs.gnu.org; Fri, 08 May 2020 11:58:22 -0400 Received: by mail-qk1-f170.google.com with SMTP id b6so918337qkh.11 for <4911@debbugs.gnu.org>; Fri, 08 May 2020 08:58:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:autocrypt:message-id:date:user-agent :mime-version:in-reply-to; bh=L7mkWptrM2LNYIxqNTSnFnrScxxPs1rIqBapvyA9lX8=; b=cCTDJLJxcygUW+pTFWnkzDbeYsuLQPsvw3UIjibaJ8nWkJUk8f/RbswWlZlsQEGGaS 8WeSjBzMkUJeXVx/n0jiNnymfM7ywifixWVq4U6XnZzAD7iOt4Z7uT5gguRhgiCKdnJj s7bfKtRnnqxHCjWh1gIKE/Y0JDg+Gdy346uujnWfE3Xr3T5+sTRzYT0d3xr0FSC94Pi+ bOfzUuVGEL3DAT/9rwcbHihuum6PCLAI+foTUnv+03OU8KtVJhA1LcakLuL3aaMcC1jl /FHIREfqimiHVm9kszL0gRQku8fCIgr+3A58Zy6HcVyP1iy3phWyXFVARHQdOQwNkk0m oVAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:autocrypt :message-id:date:user-agent:mime-version:in-reply-to; bh=L7mkWptrM2LNYIxqNTSnFnrScxxPs1rIqBapvyA9lX8=; b=eWCva2T7OrlvPMsl83YVcQ+b3C8/7ec3q1PYzKJA530b8vqWpjnKIJzDQ7NFwhjXtY 3jixlnlbMY2AUdW2Pt1+9xWg5DEvhI16n80CV6cxKJUIexiRZo14941EaA2FwWUqqxqe qtljdyNbw5zTLseq1iIH987YjAQbL2lY+6256tNrbzvzr6xNfAelGnOhRhMBnFRAUa7l Tzw8zA0Iw1uC3Ltq12vSRgGEHohwNneDCMpX2V6er+DpuipkaMPcUGS7C4+HJEx0HJ7w CsWltgcEgL/ftNMBxWPk71MWtIaTa7RxouLfRLjki8/JNsbbxAeMYYd7OI7arpl3T/ql Zx7Q== X-Gm-Message-State: AGi0PuYZTikrMrezFXTGq+7Mp598OwjBQmjcU30XorJvQorX802ri1ym plv+v6z0S7cqQOUVu4bely8= X-Google-Smtp-Source: APiQypLBJ0Ojn+H+M4zXLd2h6O3Qn1v/mz8M/31Rl8ZQwZwIRs/dXgUqj4zfYLGdQFA2KwlZacf4yA== X-Received: by 2002:a37:bd45:: with SMTP id n66mr3665522qkf.108.1588953496643; Fri, 08 May 2020 08:58:16 -0700 (PDT) Received: from ?IPv6:2601:184:4180:66e7:4d17:b25e:8d9:2188? ([2601:184:4180:66e7:4d17:b25e:8d9:2188]) by smtp.gmail.com with ESMTPSA id 132sm1463253qkj.117.2020.05.08.08.58.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 08 May 2020 08:58:15 -0700 (PDT) Subject: Re: bug#4911: mouse-face property should merge face attributes, not replace To: Eli Zaretskii References: <8452d0c8-afc3-bdb8-2c88-f66dc770c3c4@gmail.com> <0955d0dd-c4fe-4feb-b68b-0ed212ccf291@default> <35268628-9ef1-8dd2-ab93-05ca1cae06be@gmail.com> <83blne74mk.fsf@gnu.org> <83a72iij8l.fsf@gnu.org> <38d17eb2-ba5b-30a6-d9ac-ec18ee7d8fe9@gmail.com> <83368aihcb.fsf@gnu.org> From: =?UTF-8?Q?Cl=c3=a9ment_Pit-Claudel?= 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 CwkIBwMCBhUIAgkKCwQWAgMBAh4BAheABQJUrRuVAhkBAAoJEPqg+cTm90wjResP/j6A9F81 5C78IKzYdYIa7dHNWi4djRdUd79iIHGeFrao6qf7NX3XZmWkpgWExeanaqS7MmJjyXYEh6La JnzojETK+LVYk2xOanKQch2QrxGZVsXFtp/h102J1yTkUKp4g3uyaVlMLDg1P4eHSJC2YHr2 GtE4HTMUW6SThZ1nJQTrSrVpxTL9hRU/O4VIycogD9++zQ3Y1KzGq5xEi+UbjmcycR0dhSSD vAqo3yU46rfgyKPT99JR0edvYAbJaw5uq35Y0y0L6/gV4Bj6c69TADeyc5iTvagPLUWfeWUv YS2M+j7EWRePRmkuBw1ZPxKlibhsfzZBtIt6jEFd+U8ES5ycm6LSqu3ryGlFuFvdrkWzO7Fp SsHo03r6jtc8nY2jnOzsuxVvakMW1JqAiIP2H57Xyv1gZWb60dJDy2k9M7SCONdFLSU6E3k1 ZjyVkWD2cDhoLV2jy11U9hxQt+OfH2M/f+1cZe5Fberz4ceQ0ssLdfOo4dcGd+MW1lixXYj/ VrZj+QmqOdpzjxyLlzd94Mj7cvNzn/bJV4af6fgY+zbGHj8POrIVrIVO0B2/lSLG2HqO+srI 38gpz8vsVuqtuA5QSPT58H3PeAn0uYetCYNammoPRbQadgQOa8z2Bns2c2HsDj4baMck8d+h PDf7MdiEAW7zE6pxQtdr0xo6EREczsFNBFStGiEBEADTKhFNyVXInTxg1rioBtixWbNr2yRt Wu+jR4ECvPW1rY2ThYQ/I2Z97irnhmFnuepIM/gGviXN2OG1+xSBGjJVN4i9chnhxTLHKc+d uqq01tD/OGItoH63MQekOPhsymUyd95Ci01nM18pTzZDghYal47Ex/j+rlM8AaBmtSbTNGN/ rTFGUMvregVqrnnrYfs/LlooxHtTAbpY19e/sZX5b9EWdsa6k074bt6ew3TQ9xm7/4grV06H vc1b0I79Rk8vPslXh9Wh6qS4+OLkvFWnwTUachInxlD4E0wdK33XaaSxarFSmnYcVrsW2Izy gPoRMYgB5oUPtmUE8F/WfhWZ0Z3P9cKXx3EP6Z25PN3UJFXr+kZpVow65bx0MFIu/N5ygbHX sQ482CQwgzg5rr3arxXB9AknHC753jSJeld1oAsy1J+hmY7iSGxjoZeL4Yoq8IINNeq1QbH0 vo9esK4hmUi2fXIg/GKoramWJ6DjiObuHOJvXkiV9QS7GVnlHq1Z2/HGN998n6nmUj7i70lk a1XiJ3LFtAcxqsnjc1hXdi2yuOnbHRhpVBIuCEsj3EKtp5zTVkAK77c5LOIIRoij9ACUaT6x D6r93jbuw5HbSHP3aW3P/jkQ3kgZXPaa6890kPe3eRqyf9iOYpcAWu71TSqQldaOZ1Nl2Ttk 1JY8UQARAQABwsFfBBgBAgAJBQJUrRohAhsMAAoJEPqg+cTm90wjqucP/3di/s4HIltDHvte Css8JYINdfkdfkt5ub75YLoBa5blPIMJ/E5HMiQ90dAnIlg0ZQ39AOJ0agyg7vNSi199Y1Kn 3TSpAAiTo5V8ry8CuyqJ+0t4czr5PUr6P+8ggFAXMSn5NbZPQHZRods3GFtO5pq/6gwWxBiO 6VcLEqeEdz+ZzusISIPtuz56biaeR5+lh3FVITvXzVHY/7mXeKKb/HKy4gwHmNnWAqrELjg1 vtTtJJnPyrTUE6vYzO1pfNs7ynfcylV5q6oloLNwChQweMfFtDHOiOv6wweLav43+28WAElD Saw618yT8fFSWYGl9tUmADoRgHfFrcHrcZ0v/27C4Gh/bbESUJqm4ik1wZPrEjIwSZJFAm5k 2wTlRMnuxT7cGZVYChG2awk5wbYqofwivGcpY1X+HSGivYXEGQmvPSdONFbgr1FUDXKgcsbw qsxaBtx407fDL8ohnWnsjqB0X6sWUjllm8Afxabwr2WCzdRut6/HIXcrFHIFjzHokIqartiO 0J0tmANHEACjmDgF6E1XlUi0SnNXDV0Us2z4843kEocj8Z6zFNQkuMy0ArQbuxVG0i5jaRaA nI6nLB+ouU4UJNUnzrVnVr2sQuruMIIb9u7DVTodwfkrEVw0aoiSW3D7CTATZcBihOo8NZjm hze1s8uad9n9PQF+gigV Message-ID: <9044f24e-ca0e-2701-ad7a-0b241f2d69a4@gmail.com> Date: Fri, 8 May 2020 11:58:13 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <83368aihcb.fsf@gnu.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="6LfaAs7gB8cx7qxc2sgJpJct8Reo01iwb" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 4911 Cc: larsi@gnus.org, 4911@debbugs.gnu.org, drew.adams@oracle.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --6LfaAs7gB8cx7qxc2sgJpJct8Reo01iwb Content-Type: multipart/mixed; boundary="kTx4rVn2LfV54GeBAK39yGJPMj3RcWrAb"; protected-headers="v1" From: =?UTF-8?Q?Cl=c3=a9ment_Pit-Claudel?= To: Eli Zaretskii Cc: drew.adams@oracle.com, 4911@debbugs.gnu.org, larsi@gnus.org Message-ID: <9044f24e-ca0e-2701-ad7a-0b241f2d69a4@gmail.com> Subject: Re: bug#4911: mouse-face property should merge face attributes, not replace References: <8452d0c8-afc3-bdb8-2c88-f66dc770c3c4@gmail.com> <0955d0dd-c4fe-4feb-b68b-0ed212ccf291@default> <35268628-9ef1-8dd2-ab93-05ca1cae06be@gmail.com> <83blne74mk.fsf@gnu.org> <83a72iij8l.fsf@gnu.org> <38d17eb2-ba5b-30a6-d9ac-ec18ee7d8fe9@gmail.com> <83368aihcb.fsf@gnu.org> In-Reply-To: <83368aihcb.fsf@gnu.org> --kTx4rVn2LfV54GeBAK39yGJPMj3RcWrAb Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 08/05/2020 11.20, Eli Zaretskii wrote: >> Cc: drew.adams@oracle.com, 4911@debbugs.gnu.org, larsi@gnus.org >> From: Cl=C3=A9ment Pit-Claudel >> Date: Fri, 8 May 2020 11:01:35 -0400 >> >>> I'm not sure I understand what you mean by "span" in general and >>> "current span" in particular. >> >> I meant a range of text with a single mouse-face property. >=20 > But if the underlying text has different face properties, the range of > text should now be divided into different "spans", no? Yes, sorry for the confusing terminology :'( Basically I meant to say that we keep the code used for locating which sp= an of text is covered by a mouse highlight; namely, we look for a range o= f text with an `eq' mouse-face value. >>> . realizing and caching 2 faces whenever we render some text which >>> has a mouse-face property; >> >> Don't we already do this, currently? >=20 > No, because we only have a single mouse-face. With this feature, we'd > have multiple ones, and they are only known when the face of the text > is being realized, because each character could have different sources > of face information, which need to be merged. Ah, I see. Right now we don't need to look at the regular faces at all; = of course. >>> . using the corresponding face when redrawing the highlighted >>> portions of text by looking at the positions of each of the >>> affected glyphs (which might be complicated if the text doesn't >>> come from a buffer) >> >> But isn't that already taken care of by the existing highlighting code= ? >=20 > No, because the existing code always uses the same mouse-face. So it > only needs to know which glyphs need to be redrawn with that single > face. Got it. My hope was that changing Mouse_HLInfo would allow us to get thi= s almost "for free" --kTx4rVn2LfV54GeBAK39yGJPMj3RcWrAb-- --6LfaAs7gB8cx7qxc2sgJpJct8Reo01iwb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEElGa8adIcPra4Jxxu+qD5xOb3TCMFAl61gZUACgkQ+qD5xOb3 TCON1w/+Jlxfg0U/izTBV8ZYPGWAY8+4hDmGoiXKdVSFTBg4o/XBLJXxOvoGvaKC fRZqt3OaWTfCTBGNmwX1U6S26EMsrHrJJ8+szdZGC6KaZLPYXfIF6sv7b31P+Oh6 Ugq59eySWirEzIuHXdNz/kI+/S7eEKXmbXQwCchC+C44J3STHgKEtc31sJFoQC5k S0y4+AweU64/BJj0JLapwvGdOiBcOUmyZtG5282uIVrOtV3jLw4FAjfnhd84srOh ComPsGBrLyO9siGE/ey/S9PFBWOapWGLllnIuts4nLOrLpfyYZBCNUjbacbkFOG0 FTGxBgtaKFvfCJY/N2q6pbpWYa34Jv8uxTYVbBvd2GQWVPASL9mKLx1FA9L2BMsG lCUYAksOsoDVe4HtLDRCJE+M10L6a/J5b37nOcoUWk+4DqLLpQGlZmFJNEVPTpTQ gQ9CKsX3cVfuivDN7QaSBHQiYBTQEVLBC7QquSy8FRvCuwW/muJxHs7bGILuV2C+ SGg4REe1uYFJw9TOuNdMq8jxSie1wrJ87QqrtauPHVfYBZWO1NSy99b2yi1YQUeG jJNwZ9DJc2RZbgY8MtX6csKP29AXjmSx/pn12T+hVaunjmGi2TVaVX5OF/aRzVBX k1TTcPcHAVbvK08GWa5SM0/dRQRkDWTWKjNpMR/mOJrtraaB41c= =fgIA -----END PGP SIGNATURE----- --6LfaAs7gB8cx7qxc2sgJpJct8Reo01iwb-- From unknown Fri Jun 20 07:14:07 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sat, 06 Jun 2020 11:24:04 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator