From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: [drew.adams@oracle.com: RE: Customize doc strings and tagstrings do not respect \\<...> and \\[...]] Date: Sun, 5 Mar 2006 07:30:19 -0800 Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1141572672 12462 80.91.229.2 (5 Mar 2006 15:31:12 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 5 Mar 2006 15:31:12 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Mar 05 16:31:10 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1FFvCK-0007BR-5e for ged-emacs-devel@m.gmane.org; Sun, 05 Mar 2006 16:31:04 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FFvCQ-0007HD-Ty for ged-emacs-devel@m.gmane.org; Sun, 05 Mar 2006 10:31:10 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FFvC8-0005kQ-VK for emacs-devel@gnu.org; Sun, 05 Mar 2006 10:30:53 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FFvC5-0005EM-Eq for emacs-devel@gnu.org; Sun, 05 Mar 2006 10:30:52 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FFvC5-0005Dn-2E for emacs-devel@gnu.org; Sun, 05 Mar 2006 10:30:49 -0500 Original-Received: from [141.146.126.228] (helo=agminet01.oracle.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.52) id 1FFvE8-0003VE-V3 for emacs-devel@gnu.org; Sun, 05 Mar 2006 10:32:57 -0500 Original-Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.186.50]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k25FUef1005633 for ; Sun, 5 Mar 2006 09:30:40 -0600 Original-Received: from rgmsgw301.us.oracle.com (localhost [127.0.0.1]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k25FUd1j028812 for ; Sun, 5 Mar 2006 08:30:39 -0700 Original-Received: from dradamslap (dhcp-amer-csvpn-gw2-141-144-73-69.vpn.oracle.com [141.144.73.69]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id k25FUcgH028804 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Sun, 5 Mar 2006 08:30:39 -0700 Original-To: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-reply-to: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:51231 Archived-At: > The point (the bug) is that the tag text should implicitly have > `substitute-command-keys' applied to it. The connection between doc strings and widget tags is not immediately apparent, but of course this could be added as a new feature. Who is to say whether the current design includes this, so that the implementation is bugged, or the design does not include this, so that this represents a new feature? I can't speak for the designers, but as a user, it seems pretty obvious to me that this is the way :tag strings should work. When I see that they don't, I report it as a bug, but the designers are free to say "That's the way it is supposed to work", to which I would reply, "Please change the design to add this useful feature." But note that this would change the rendition of existing :tag strings since certain construct in the text would have to be quoted now. What constructs are those? How would they have to be quoted? I'm not aware of ever having to quote anything in a doc string? Just what is the limitation that `substitute-command-keys' imposes? What is an example of an existing :tag string that would be negatively impacted? If a programmer wanted the behavior we get currently, then s?he would be out of luck. I don't know of a way to "quote" things to protect against `substitute-command-keys', however. Current only doc strings are filtered through substitute-command-keys (via documentation-property). > No. This is the correct rendition of \ when my-map is not > defined. > > If one defines "correct rendition" by whatever the program does currently, > then of course there can be no bug. "Circulez, il n'y a rien a voir!" That's how substitute-command-keys has always been working, and it is not a useless feature. I didn't say anything to the contrary. That feature is useful, as is, for `substitute-command-keys'. But raw `substitute-command-keys' with that feature is not appropriate for this context. The point is that this is not just `substitute-command-keys'; it is use of that function in a particular context. You are arguing that the implementation does what it does. I am saying that the implementation doesn't do the right thing - it's not enough to just use `substitute-command-keys' with no thought to the context. An error message like this should be handled more gracefully for the user. It helps to interpret subsequent renditions of \[...] (the commands might be bound in a different key map that is current at this point). I have nothing against the reporting of the warning. The point is that when a function passes up an indication of an error condition to its caller, it is up to the calling function to DTRT with that info, not necessarily just dump it to the screen. In this case, it would be enough to 1) insert the original text (so that the error message becomes intelligible, instead of appearing to be missing a part), 2) insert the error message _after_ the buttons and original text. IOW, if the garbling of the message and original text and splicing around the button were fixed, things would be fine. Admittedly, this is a minor, cosmetic bug. The bug originally reported (need to apply `substitute-command-keys' to :tag text) is more important, as it affects fairly important functionality (IMO).