From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Escaping a string for substitute-command-keys Date: Sat, 05 Oct 2019 11:13:34 +0300 Message-ID: <83y2xz4nkh.fsf@gnu.org> References: <14423aa7-36c3-9ab7-6483-d43624f99e17@gmail.com> <83pnjd7pud.fsf@gnu.org> <83h84p7nih.fsf@gnu.org> <837e5l7j8n.fsf@gnu.org> <83imp461do.fsf@gnu.org> <835zl364yx.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="191842"; mail-complaints-to="usenet@blaine.gmane.org" Cc: emacs-devel@gnu.org To: =?utf-8?Q?Cl=C3=A9ment?= Pit-Claudel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 05 10:13:55 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iGfCM-000nlq-IJ for ged-emacs-devel@m.gmane.org; Sat, 05 Oct 2019 10:13:54 +0200 Original-Received: from localhost ([::1]:54736 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iGfCL-0008Ff-7z for ged-emacs-devel@m.gmane.org; Sat, 05 Oct 2019 04:13:53 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57745) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iGfCD-0008FI-7R for emacs-devel@gnu.org; Sat, 05 Oct 2019 04:13:46 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:35774) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1iGfCD-00043Z-3M; Sat, 05 Oct 2019 04:13:45 -0400 Original-Received: from [176.228.60.248] (port=2489 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1iGfCC-0007rT-CP; Sat, 05 Oct 2019 04:13:44 -0400 In-reply-to: (message from =?utf-8?Q?Cl=C3=A9ment?= Pit-Claudel on Sat, 5 Oct 2019 04:04:34 -0400) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:240601 Archived-At: > Cc: emacs-devel@gnu.org > From: Clément Pit-Claudel > Date: Sat, 5 Oct 2019 04:04:34 -0400 > > > I guess we need to add some feature to control whether help-echo gets > > run through substitute-command-keys, or add an alternative to > > help-echo that works exactly like it, but without substitutions. > > Patches welcome. > > Sounds good, and I can work on the patch. I think I like the first solution better, if we can come up with something elegant: the second case will force us to define priorities, and besides we already have kbd-help in addition to help-echo. > > What about the following: before performing a conversion, substitute-command-keys could check a property of the string that it receives, say help-echo-conversion, and if that property is nil it would not perform the conversion. I'd prefer a property like help-echo-inhibit-substitution that is non-nil, to inhibit the call to substitute-command-keys. A value of nil is easy to confuse with no property at all. > Alternatively, there's the option of performing conversion only on those 'help-echo' properties that are string, and leaving (the output of) the ones that are functions untouched. I think they all should be converted, otherwise we have an inconsistency of the kind you mentioned.