From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Consistent face for keys in *Help* and `substitute-command-keys' Date: Fri, 05 Mar 2021 20:58:14 +0200 Message-ID: <83a6rhxwah.fsf@gnu.org> References: <87h7m5iagw.fsf@gnus.org> <83blc9tnvz.fsf@gnu.org> <83y2fcrzkt.fsf@gnu.org> <831rd4romg.fsf@gnu.org> <83zgzsq7xn.fsf@gnu.org> <83v9afriqp.fsf@gnu.org> <83zgzjhvdn.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24858"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, emacs-devel@gnu.org To: Stefan Kangas Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Mar 05 19:59:44 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lIFfq-0006LV-BR for ged-emacs-devel@m.gmane-mx.org; Fri, 05 Mar 2021 19:59:42 +0100 Original-Received: from localhost ([::1]:43938 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lIFfl-0006mb-8b for ged-emacs-devel@m.gmane-mx.org; Fri, 05 Mar 2021 13:59:41 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60554) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lIFei-0005YE-M1 for emacs-devel@gnu.org; Fri, 05 Mar 2021 13:58:32 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:48405) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lIFeh-0004Kv-VP; Fri, 05 Mar 2021 13:58:31 -0500 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3303 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lIFef-0006Eo-6K; Fri, 05 Mar 2021 13:58:29 -0500 In-Reply-To: (message from Stefan Kangas on Fri, 5 Mar 2021 10:18:25 -0600) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:266034 Archived-At: > From: Stefan Kangas > Date: Fri, 5 Mar 2021 10:18:25 -0600 > Cc: larsi@gnus.org, emacs-devel@gnu.org > > >> => #("yxy" 0 1 (face italic) 1 2 (face (italic bold)) 2 3 (face italic)) > > > > That's because you add a property which was unspecified by the > > original face. But in the tooltip case, the function tooltip-show > > propertizes the entire text it receives with the 'tooltip' face, so > > any face attributes in the text that are also specified by the > > 'tooltip' face will be overwritten. So, for example, if the tooltip > > text had a :background attribute, that attribute would be overwritten > > by the background color of the 'tooltip' face. Isn't that what you > > see? > > But that just comes down to which face takes priority, right? So if we > we would need to set the APPEND argument of `add-face-text-property' to > t. This would take care of the conflicting colors, but that's not the original problem which caused us to talk about tooltips. The original problem was that someone could customize the help-key-binding face to specify size as well. What do you see then? > + (add-face-text-property 0 (length text) 'tooltip t text) This should have a comment explaining why we use a non-nil APPEND argument.