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#1169: 23.0.60; (substitute-command-keys "\\{...}") adds extra newline Date: Wed, 30 May 2012 07:44:34 -0700 Message-ID: References: <004801c92e4e$9b8018c0$0200a8c0@us.oracle.com> <87ehq251b9.fsf@gnu.org> <8762bdyd2p.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1338389158 7047 80.91.229.3 (30 May 2012 14:45:58 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 30 May 2012 14:45:58 +0000 (UTC) Cc: 1169@debbugs.gnu.org To: "'Chong Yidong'" , "'Lars Magne Ingebrigtsen'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed May 30 16:45:55 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1SZk9k-0005Fs-7g for geb-bug-gnu-emacs@m.gmane.org; Wed, 30 May 2012 16:45:48 +0200 Original-Received: from localhost ([::1]:33264 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SZk9j-000490-Rw for geb-bug-gnu-emacs@m.gmane.org; Wed, 30 May 2012 10:45:47 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:52621) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SZk9Y-000485-3g for bug-gnu-emacs@gnu.org; Wed, 30 May 2012 10:45:45 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SZk9V-0006R4-I3 for bug-gnu-emacs@gnu.org; Wed, 30 May 2012 10:45:35 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:40835) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SZk9V-0006Qd-Ez for bug-gnu-emacs@gnu.org; Wed, 30 May 2012 10:45:33 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1SZkAv-0002hJ-M1 for bug-gnu-emacs@gnu.org; Wed, 30 May 2012 10:47:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 30 May 2012 14:47:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 1169 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: fixed Original-Received: via spool by 1169-submit@debbugs.gnu.org id=B1169.133838917610320 (code B ref 1169); Wed, 30 May 2012 14:47:01 +0000 Original-Received: (at 1169) by debbugs.gnu.org; 30 May 2012 14:46:16 +0000 Original-Received: from localhost ([127.0.0.1]:50381 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SZkAB-0002gO-O1 for submit@debbugs.gnu.org; Wed, 30 May 2012 10:46:15 -0400 Original-Received: from acsinet15.oracle.com ([141.146.126.227]:17350) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SZkA9-0002gD-SM for 1169@debbugs.gnu.org; Wed, 30 May 2012 10:46:14 -0400 Original-Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4UEibO1017022 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 30 May 2012 14:44:37 GMT Original-Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q4UEiaMY002959 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 May 2012 14:44:36 GMT Original-Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q4UEiZJa028957; Wed, 30 May 2012 09:44:35 -0500 Original-Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 30 May 2012 07:44:35 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <8762bdyd2p.fsf@gnu.org> Thread-Index: Ac0+bfss8lBYjA7jRPCnUrKup3SLEQAAo7TA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) 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:60520 Archived-At: > >> I've now made the change, > > > > This change breaks the highlighting code in `help-make-xrefs' which > > assumes that a list of key bindings produced by > > substitute-command-keys (in `documentation') ends with an extra blank line > > Thanks. I've reverted the change in the emacs-24 branch, and added a > note to the docstring of substitute-command-keys that the two newlines > are needed by `help-make-xrefs'. Huh? Two newlines is the wrong thing. It is the point of this bug report. If some other fix is needed than the one that you made, fine. Just DTRT. Sounds like `help-make-xrefs' needs to be fixed - dunno. In any case, the extra newline still needs to be removed. It is simply wrong - doesn't belong in `substitute-command-keys' - is not part of its mission. And you added your note to the _doc string_? Of `substitute-command-keys'? If you need to make a note that this bug still needs to be fixed then that should be done elsewhere than a doc string. There is absolutely nothing in the purpose of `substitute-command-keys' that constrains it or invites it to add an extra newline. Quite the contrary. `substitute-command-keys' is a very general utility function. It is not some helper routine for `help-make-xrefs'. Bending it to fix inadequate code in `help-make-xrefs' is _way_ wrong. And putting that kind of note into its doc string is doubly wrong. To repeat, from the bug report: > If text is added after the returned string, then it should be up > to *that* text to start with a \n if it wants a blank separator line. > If, for example, it starts instead with ^L, then the current code > includes an extra blank line before the form feed. > > It should be up to the *calling* function to decide whether it wants > a blank line at the end - *only* the calling function knows the > context and whether such a line is appropriate.