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: unhelpful menu keybinding notes Date: Mon, 17 Apr 2006 09:57:05 -0700 Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1145293057 19351 80.91.229.2 (17 Apr 2006 16:57:37 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 17 Apr 2006 16:57:37 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 17 18:57:34 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 1FVX2U-0008FJ-Sb for ged-emacs-devel@m.gmane.org; Mon, 17 Apr 2006 18:57:27 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FVX2U-00045A-HY for ged-emacs-devel@m.gmane.org; Mon, 17 Apr 2006 12:57:26 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FVX2I-00044Z-8u for emacs-devel@gnu.org; Mon, 17 Apr 2006 12:57:14 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FVX2E-000445-5q for emacs-devel@gnu.org; Mon, 17 Apr 2006 12:57:13 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FVX2D-00043u-TC for emacs-devel@gnu.org; Mon, 17 Apr 2006 12:57:09 -0400 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 1FVX2u-0000Gr-Iu for emacs-devel@gnu.org; Mon, 17 Apr 2006 12:57:52 -0400 Original-Received: from rgmsgw300.us.oracle.com (rgmsgw300.us.oracle.com [138.1.186.49]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k3HGv66m009644 for ; Mon, 17 Apr 2006 11:57:08 -0500 Original-Received: from dradamslap (dradams-lap.us.oracle.com [130.35.177.126]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id k3HGv59Q008621 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 17 Apr 2006 10:57:06 -0600 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.1807 X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE 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:52964 Archived-At: In some parts of Emacs we use another trick: make and use an alias, like `advertised-undo'. I think this is a bad solution because C-h f undo RET then lists all bindings except for the "advertised" one C-x u. I agree. Maybe a better solution is to add an `advertised-binding' property to the function's symbol: (put 'undo 'advertised-binding [?\C-x ?u]) which could be used similarly to the :key-sequence property in menus (i.e. it's used if the key seuqnece is indeed bound to the specified command). Some other ideas were kicked around previously. I don't recall them, but it's worth discussing all of them sometime after the release. I like your idea, but: - What to do if the key sequence is not bound to the specified command and there are several bindings? Which to pick? - It might increase maintenance (but so might other solutions): Changing the bindings in the library would also mean updating this property. One question to consider is whether we want to allow control over what gets communicated 1) at the point of use of `substitute-command-keys' or a doc string or 2) at some earlier, more general point - or both. For #2, a library might (somehow, perhaps using more or less the mechanism you proposed) specify a list of bindings, in preference order, that would apply to all uses of `substitute-command-keys' and all doc strings. For #1, we might devise some way to indicate the preferred binding to use at the point of call. For example (just thinking out loud; not a proposal), "\\[((kbd "C-x") (kbd SPC) (kbd "C-M-"))...]" might stipulate using binding (kbd "C-x") if applicable, else (kbd SPC) if applicable, else (kbd "C-M-"). There might also be some way to specify a default for the case where none were applicable. Both general presciption (#2) and spec at point of use (#1) could of course be used together, the latter (#1) taking precedence.