[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: C-x &
From: |
Drew Adams |
Subject: |
RE: C-x & |
Date: |
Mon, 6 Aug 2018 13:57:46 -0700 (PDT) |
> Yes. I haven't said otherwise, at least in my last email.
>
> > If you wanted to call command `universal-async-argument' a "prefix
> > command" you could do so. But `C-x &' is not a prefix command or any
> > other kind of command.
>
> I haven't said that `C-x &' is any kind of command, at least in my last
> email.
Right. You didn't. But some others did. And it wasn't obvious (to me) that you
didn't mean to say that `C-x &' is a "prefix command". If you meant only that
`universal-sync-argument' is a prefix command then, as I said, that's OK by me.
(The doc should then define "prefix command".)
> >> So I don't see what's wrong with "prefix command" - it is a command
> >> which precedes another command.
> >
> > Command `universal-async-argument', when invoked, precedes invocation
> > of the command bound to the key sequence read by
> > `universal-asyn-argument'. Yes.
> >
> > And using `C-x &' precedes reading of that second key sequence. But
> > neither of those things make `C-x &' into a command, prefix, postfix,
> > or *fix.
>
> Again, I haven't said that `C-x &' is a command, in my last email.
>
> Let's agree the obvious: `universal-async-argument' is a command, by
> default bound to the key sequences `C-x &' and `M-x u n i v e r s a l -
> a s y n c - a r g u m e n t RET.'
Agreed.
(Although I wouldn't say that the command is bound to `M-x...'. That sequence
of keys invokes `u-a-a', but the command is not bound to it. We just don't say
that kind of thing in Emacs. The key sequences bound to a command are well
defined, and they don't include `M-x' followed by keys spelling out the command
name. Similarly, the command is not bound to `M-x uni-a-arg TAB RET' etc.)
> The only raison d'être of `universal-async-argument' is to read another
> key sequence, which invokes the command bound to that key sequence. This
> means, the command `universal-async-argument' always precedes another
> command, which I call a prefix in my understanding.
Agreed. (Although the command that is preceded by `u-a-a' is, if anything, a
suffix of it, not a prefix. I suspect you just misspoke in the last phrase.)
> Therefore, I've proposed to call `universal-async-argument' a "prefix
> command".
OK by me (where "it" is the command, not `C-x &'). "Prefix command" then needs
to be described/defined/explained in the manual.
> The Emacs manual distinguishes between commands and the key (sequence) a
> command is bound to. But it explicitely says, that both could be used
> equal:
>
> --8<---------------cut here---------------start------------->8---
> In this manual, we will often speak of keys like ‘C-n’ as commands,
> even though strictly speaking the key is bound to a command.
> --8<---------------cut here---------------end--------------->8---
>
> See (info "(emacs) Commands")
Yeah. I was afraid someone might quote that passage. ;-)
I don't have a problem with that text, because its purpose is to state that we
sometimes speak that way even though it is not really correct. It's not
defining a key sequence as the command that it's bound to - quite the opposite.
It both (1) points out that a key sequence is not the same thing as the command
that it's bound to and (2) mentions that sometimes we gloss over that
difference, for brevity and when the context makes the meaning clear.
> So it would be also allowed to speak about the key sequence `C-x &' as a
> command, but I don't insist on this if it makes you feel bad.
It would be allowed to say "command `C-x &'", yes, for brevity. That's a far
cry from defining a new term "prefix command" and applying it to `C-x &'.
(Especially since there is also a notion of prefix key, which is something
quite different.)
In sum, I don't have a problem with calling `universal-async-argument' a
"prefix command", if that term is defined in the manual.
----
About the command name (FWIW):
I'm not crazy about the name "universal-async-argument'. I realize that it's
modeled on `universal-argument', and I can live with it. But I wish that both
of those commands were named differently. (No, I'm not proposing a name change
for `u-a' at this late date.)
`u-a-a' doesn't necessarily provide a (non-default) prefix arg to a command. It
invokes a command (bound to a key sequence that it reads).
It's somewhat akin to `execute-extended-command' or
`comint-redirect-send-command'. Those read a command name and not a key
sequence, so in that respect they differ. But I think it might be better for
`u-a-a' to be named `<something>-command', where <something> does not suggest
"universal argument".
Unlike `u-a', you need not provide a prefix arg to `u-a-a'. It's not really the
same kind of command. `u-a-a' does accept and take into account a prefix arg,
if you provide one; but it's not required (IIUC). (Maybe I'm wrong about this.
What prefix arg does bare `C-x &' provide? Does it provide `(4)', as `C-u' does?
No, I don't feel strongly about the command name. Yes, I understand why you
proposed "universal-async-argument". But I think its association with
`universal-argument' confuses more than clarifies. No, I don't have a great
suggestion for the command name. Ideally it should convey "read a key sequence
and invoke the command bound to it" (and the doc string would explain that it
will also read a prefix arg and pass that to the command). Maybe
`invoke-command-bound-to' or some such.
- Re: Introducing thread-safe Tramp, (continued)
- Re: Introducing thread-safe Tramp, Eli Zaretskii, 2018/08/04
- Re: Introducing thread-safe Tramp, Michael Albinus, 2018/08/04
- Re: Introducing thread-safe Tramp, Eli Zaretskii, 2018/08/04
- Re: Introducing thread-safe Tramp, Michael Albinus, 2018/08/05
- Re: Introducing thread-safe Tramp, Eli Zaretskii, 2018/08/05
- Re: Introducing thread-safe Tramp, Michael Albinus, 2018/08/06
- RE: Introducing thread-safe Tramp, Drew Adams, 2018/08/06
- C-x & (was: Introducing thread-safe Tramp), Michael Albinus, 2018/08/06
- RE: C-x & (was: Introducing thread-safe Tramp), Drew Adams, 2018/08/06
- Re: C-x &, Michael Albinus, 2018/08/06
- RE: C-x &,
Drew Adams <=
- RE: C-x &, Drew Adams, 2018/08/06
- Re: C-x &, Michael Albinus, 2018/08/07
- Re: C-x &, Michael Albinus, 2018/08/07
- Re: Introducing thread-safe Tramp, Stefan Monnier, 2018/08/06
- Re: Introducing thread-safe Tramp, Eli Zaretskii, 2018/08/06
- C-x & (was: Introducing thread-safe Tramp), Michael Albinus, 2018/08/06
- Re: Introducing thread-safe Tramp, Filipp Gunbin, 2018/08/06
- Re: Introducing thread-safe Tramp, Michael Albinus, 2018/08/07
- Re: Introducing thread-safe Tramp, Stephen Berman, 2018/08/07
- Re: Introducing thread-safe Tramp, Robert Pluim, 2018/08/07