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#22107: 25.1; Wrong docstring for this-single-command-keys Date: Sun, 13 Dec 2015 09:25:50 -0800 (PST) Message-ID: References: <838u54dgg2.fsf@gnu.org> <83mvtkb882.fsf@gnu.org> <83io47blbq.fsf@gnu.org> <83egeu9lze.fsf@gnu.org> <83eget8gos.fsf@gnu.org> <83poyd6m1b.fsf@gnu.org> <837fkk6qyq.fsf@gnu.org> <83vb8367jj.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1450027644 314 80.91.229.3 (13 Dec 2015 17:27:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 13 Dec 2015 17:27:24 +0000 (UTC) Cc: John Wiegley , 22107@debbugs.gnu.org To: bruce.connor.am@gmail.com, Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Dec 13 18:27:11 2015 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 1a8AQQ-0006UR-D6 for geb-bug-gnu-emacs@m.gmane.org; Sun, 13 Dec 2015 18:27:10 +0100 Original-Received: from localhost ([::1]:56008 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a8AQP-0004Y2-KZ for geb-bug-gnu-emacs@m.gmane.org; Sun, 13 Dec 2015 12:27:09 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40834) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a8AQL-0004Xq-W4 for bug-gnu-emacs@gnu.org; Sun, 13 Dec 2015 12:27:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a8AQI-0002za-OS for bug-gnu-emacs@gnu.org; Sun, 13 Dec 2015 12:27:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:42744) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a8AQI-0002z6-L5 for bug-gnu-emacs@gnu.org; Sun, 13 Dec 2015 12:27:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1a8AQI-0007fK-CI for bug-gnu-emacs@gnu.org; Sun, 13 Dec 2015 12:27:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 13 Dec 2015 17:27:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 22107 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 22107-submit@debbugs.gnu.org id=B22107.145002756329401 (code B ref 22107); Sun, 13 Dec 2015 17:27:02 +0000 Original-Received: (at 22107) by debbugs.gnu.org; 13 Dec 2015 17:26:03 +0000 Original-Received: from localhost ([127.0.0.1]:50346 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1a8APL-0007e9-7F for submit@debbugs.gnu.org; Sun, 13 Dec 2015 12:26:03 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:24201) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1a8API-0007df-NV for 22107@debbugs.gnu.org; Sun, 13 Dec 2015 12:26:01 -0500 Original-Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id tBDHPsMe001616 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 13 Dec 2015 17:25:54 GMT Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id tBDHPqfM016142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 13 Dec 2015 17:25:53 GMT Original-Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by userv0122.oracle.com (8.13.8/8.13.8) with ESMTP id tBDHPq2l002679; Sun, 13 Dec 2015 17:25:52 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] X-Source-IP: userv0021.oracle.com [156.151.31.71] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.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:109931 Archived-At: > >> Stefan, can you summarize an argument for why it should change in 25.1= ? > > > > Because it's better to get rid of all the C-u special case handling and > > make C-u be a normal command so that GNU ELPA packages can implement > > their own form of prefix command. That's a bit vague, even as a summary. > I think we should do this. Why do you think so? > > The immediate need for the new behavior is to be able to implement > > C-x 4 and C-x 5 as prefix argument (rather than keymaps) so as to > > be able to get rid of all the foo-other-window and foo-other-frame > > and the concomitant need to find key bindings for them. Caveat: I have not been following this thread much, so it's not very clear to me what is being proposed, or why. So yes, I am relatively uninformed about this. I can say that it sounds like what is being considered will likely break some of my code, including key completion (in Icicles). Why the change? I don't see anything broken that needs "fixing" here. I know that Stefan has long touted getting rid of separate `*-other-[window|frame]' commands as a great idea. I disagree with that. To me that sounds like both a YAGNI and painting yourself into a corner. AFAICT, what Stefan has proposed, previously at least, increases one-size-fits-all rigidity, with no benefit other than dispensing with the need to define and bind separate `*-other-*' commands. To me, being able to define, or not define, such commands individually, and to make their behaviors be anything one likes, is a plus, not a minus. I don't see the "bother" of defining and binding them to be a giant hurdle which should be eliminated by redesigning the longstanding `C-u' and `C-x [45]' behavior. Straitjacketing `C-x [45]...' bindings to automatically be only a predefined "other" version of the command that is bound to `C-x ...' (without [45]), would be a step backward, IMO. (A macro to define & bind such a command could perhaps suffice to accomplish only that, when desired, possibly with the addition of a hook that the macro can use. That would not impose such command definitions and bindings everywhere. But even without such a macro, the typical definition and binding of an `*-other-*' command amounts to only a few lines of code. Changing how `C-u' is implemented will also likely break my code that echoes the prefix arg when the minibuffer is active (e.g., for individual minibuffer keys that perform actions). (In Icicles it is common to use minibuffer keys that act on one or more completion candidates. Such keys can make use of the prefix arg, so it is important to echo it in this context.) Another consideration, but minor: If the `*-other-*' commands are eliminated then you will presumably no longer be able to invoke them using `M-x'. The hard-coded `C-x [45]' keys will, in effect, replace the commands that have (sometimes) been bound to them. I like having not only a key but a command that is associated with it - which I can invoke in various ways. (That's the basic Emacs design.) AFAICT, special-casing `C-x [45]' - making it exceptional, is oddly enough being made as an argument in favor of more consistency. Yes, one person's consistency can be another person's bother. I, for one, am not bothered by the need (and possibility) to define separate `*-other-*' commands.