all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: bruce.connor.am@gmail.com, Stefan Monnier <monnier@iro.umontreal.ca>
Cc: John Wiegley <jwiegley@gmail.com>, 22107@debbugs.gnu.org
Subject: bug#22107: 25.1; Wrong docstring for this-single-command-keys
Date: Sun, 13 Dec 2015 09:25:50 -0800 (PST)	[thread overview]
Message-ID: <fa7364eb-7d47-4b3e-9661-ad897361731b@default> (raw)
In-Reply-To: <CAAdUY-Lv-78fn4WXJL6Wukzp1+Ba0o654G=AHo5RrcAE=dPu_A@mail.gmail.com>

> >> 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.





  parent reply	other threads:[~2015-12-13 17:25 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-07 15:42 bug#22107: 25.1; Wrong docstring for this-single-command-keys Artur Malabarba
2015-12-07 18:10 ` Glenn Morris
2015-12-07 21:46   ` Artur Malabarba
2015-12-07 21:55     ` Glenn Morris
2015-12-07 22:10       ` Artur Malabarba
2015-12-08  1:20         ` Glenn Morris
2015-12-08 12:01           ` Artur Malabarba
2015-12-08 16:59             ` Eli Zaretskii
2015-12-09  3:28               ` Stefan Monnier
     [not found]                 ` <83mvtkb882.fsf@gnu.org>
2015-12-09  4:53                   ` Stefan Monnier
     [not found]                     ` <83io47blbq.fsf@gnu.org>
2015-12-10 18:34                       ` Stefan Monnier
2015-12-10 18:37                         ` Stefan Monnier
2015-12-10 18:50                           ` Eli Zaretskii
2015-12-11  4:17                             ` Stefan Monnier
     [not found]                               ` <83eget8gos.fsf@gnu.org>
2015-12-11 14:49                                 ` Stefan Monnier
     [not found]                                   ` <83poyd6m1b.fsf@gnu.org>
2015-12-12  3:57                                     ` Stefan Monnier
2015-12-12  4:28                                       ` Stefan Monnier
2015-12-12  7:55                                         ` Eli Zaretskii
2015-12-12 14:25                                           ` Stefan Monnier
2015-12-12 14:55                                             ` Eli Zaretskii
2015-12-12 23:34                                               ` John Wiegley
2015-12-13  4:16                                                 ` Stefan Monnier
2015-12-13 10:12                                                   ` Artur Malabarba
2015-12-13 15:37                                                     ` Eli Zaretskii
2015-12-13 20:53                                                       ` Artur Malabarba
2015-12-14  3:27                                                         ` Eli Zaretskii
2015-12-14 13:52                                                           ` Artur Malabarba
2015-12-13 15:53                                                     ` Stefan Monnier
2015-12-13 17:25                                                     ` Drew Adams [this message]
2015-12-13 20:15                                                       ` Stefan Monnier
2020-09-07 15:26                             ` Lars Ingebrigtsen
2020-10-07  4:10                               ` Lars Ingebrigtsen
2015-12-10 18:49                         ` Eli Zaretskii
2015-12-11  4:24                           ` Stefan Monnier
     [not found]                             ` <83bn9x8g12.fsf@gnu.org>
2015-12-11 14:47                               ` Stefan Monnier
2015-12-11  4:17 ` Stefan Monnier
2015-12-11 13:10   ` Artur Malabarba
2015-12-11 14:44     ` Stefan Monnier
2015-12-11 15:39       ` Artur Malabarba
2015-12-12  4:06         ` Stefan Monnier
2016-05-11 13:33 ` bug#22107: this-command-keys no longer returns prefix argument Kaushal Modi
2016-05-11 14:02   ` Eli Zaretskii
2016-05-11 14:08     ` Kaushal Modi
2016-05-11 14:22       ` Stefan Monnier
2016-05-13 11:52         ` Kaushal Modi
2016-05-13 14:10           ` Eli Zaretskii
2016-05-13 15:00             ` Kaushal Modi
2016-05-11 14:18     ` Stefan Monnier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=fa7364eb-7d47-4b3e-9661-ad897361731b@default \
    --to=drew.adams@oracle.com \
    --cc=22107@debbugs.gnu.org \
    --cc=bruce.connor.am@gmail.com \
    --cc=jwiegley@gmail.com \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.