From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.bugs Subject: bug#8951: 24.0.50; [PATCH] enhancement request: buttonize key names Date: Wed, 6 Jul 2011 12:55:05 -0700 Message-ID: References: <375C29E7AB4048148D18B461FC1E02F1@us.oracle.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1309983375 6866 80.91.229.12 (6 Jul 2011 20:16:15 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 6 Jul 2011 20:16:15 +0000 (UTC) Cc: 8951@debbugs.gnu.org To: "'Stefan Monnier'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Jul 06 22:16:10 2011 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QeYW2-0002vK-B8 for geb-bug-gnu-emacs@m.gmane.org; Wed, 06 Jul 2011 22:16:10 +0200 Original-Received: from localhost ([::1]:44493 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QeYW0-0006kR-IB for geb-bug-gnu-emacs@m.gmane.org; Wed, 06 Jul 2011 16:16:09 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:45801) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QeYCb-00016h-NW for bug-gnu-emacs@gnu.org; Wed, 06 Jul 2011 15:56:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QeYCZ-0005A9-Dl for bug-gnu-emacs@gnu.org; Wed, 06 Jul 2011 15:56:05 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:38385) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QeYCY-00059z-NG for bug-gnu-emacs@gnu.org; Wed, 06 Jul 2011 15:56:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1QeYCY-0004Ej-BR; Wed, 06 Jul 2011 15:56:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 06 Jul 2011 19:56:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8951 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 8951-submit@debbugs.gnu.org id=B8951.130998212516223 (code B ref 8951); Wed, 06 Jul 2011 19:56:02 +0000 Original-Received: (at 8951) by debbugs.gnu.org; 6 Jul 2011 19:55:25 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QeYBv-0004Db-PV for submit@debbugs.gnu.org; Wed, 06 Jul 2011 15:55:24 -0400 Original-Received: from rcsinet15.oracle.com ([148.87.113.117]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QeYBu-0004DL-29 for 8951@debbugs.gnu.org; Wed, 06 Jul 2011 15:55:23 -0400 Original-Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p66JtEGP003935 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 6 Jul 2011 19:55:16 GMT Original-Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p66JtDto005699 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Jul 2011 19:55:13 GMT Original-Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p66Jt7hf028196; Wed, 6 Jul 2011 14:55:08 -0500 Original-Received: from dradamslap1 (/10.159.55.239) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 06 Jul 2011 12:55:07 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 Thread-Index: Acw8DWolyyPRNMK5QRGKdlakReKKZQABhkgg X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4E14BDA4.0075:SCFMA922111,ss=1,re=-4.000,fgs=0 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Wed, 06 Jul 2011 15:56:02 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:48122 Archived-At: > >> getting rid of the C version and only using the new Elisp version. > > See the emacs-devel thread, where I addressed both of these things. > > http://lists.gnu.org/archive/html/emacs-devel/2011-06/msg01081.html > > I don't think that quite addresses it. But, I guess it does > indirectly: you apparently haven't found problematic cases > that require distinguishing help-substitute-command-keys from > substitute-command-keys. Instead you just personally prefer > to keep the option whether to buttonize or not. Yes, I suggested that `substitute-command-keys' itself be modified to accept the optional argument. I did not try to replace `substitute-command-keys' directly with a version that has the optional arg to buttonize, because (a) I didn't want to hack the C code and (b) I didn't want to bother writing the \\{...} code in Lisp. > > I wrote Lisp, but if someone wants to instead patch the C code for > > `substitute-command-keys' then go for it. > > No, I'm not interested in making this C code more complicated. I want > to go the other way around. Glad to hear that. That's my preference too. > > The Lisp version I wrote still invokes the original C code for the > > \\{...} case. I did not try to rewrite that in Lisp. > > I see. It should be pretty easy to do, easy exporting the needed > underlying C function to Elisp, or rewriting it in Elisp (there's no > good reason to have describe-buffer-bindings written in C, really). Please, go for it. I agree. > > 1. Keep the Lisp code I wrote (or similar), renaming it to > > `substitute-command-keys'. > > Sounds good. > > > 2. Simplify the original C code to handle just the \\{...} case, > > rename that function, and use it in #1 to handle the \\{...} parts > > (just as now, but under its new, {}-specific name). > > Sounds good. > > > Alternatively, you can write #2 in Lisp, if you like. > > Sounds good as well. > > > Wrt your question of whether "there are places where such buttons > > become annoying": I would say that it does not matter whether there > > are currently any such places. There is no reason not to treat the > > buttonizing as optional. > > Of course there's the reason that providing a choice is never free, so > we should only provide the choice if there's a good reason for it. I gave this reason to make it optional: \\[], \\<>, \\{} are about mapping command names to corresponding key descriptions - nothing more. That in itself does not say anything about help buffers and interactivity (clicking, RET). The function is just a string transducer. The common use case for that is of course doc. And the common use case for the doc use case is a help buffer. But a string of doc is more general than a help buffer, both in terms of string vs buffer and in terms of the need for button text properties (interactivity). There could be applications of this function to produce a readable string that do not involve a button-clicking interactive context. "providing a choice is never free" - What's the cost? And what's the cost of always doing the extra lifting of creating buttons? Code maintenance will be at least as easy if it is optional, possibly easier since the additional buttonizing part is well separated. And not creating buttons (properties) saves a little time and memory (but that's probably not very significant). No, I don't feel strongly about making buttonizing optional. But I don't see why you wouldn't do that.