[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Introducing thread-safe Tramp
From: |
Drew Adams |
Subject: |
RE: Introducing thread-safe Tramp |
Date: |
Sun, 5 Aug 2018 08:36:23 -0700 (PDT) |
> > Even `C-u' (`universal-argument') is not a prefix argument. It is a command
> > that begins reading a prefix argument and that, possibly together with
> other
> > commands (such as `digit-argument') provides that prefix argument to a
> > followup command.
>
> We think of C-u as beginning a prefix argument, without exception.
> Sometimes the prefix argument consists of C-u and nothing but C-u.
If your point is that my "possibly" needs to be scoped only to the "other
commands", and that `C-u' _always_ provides a prefix arg, even when alone, then
yes, of course - that's what I meant for the scope of the "possibly".
My point was really that `C-u' is a key sequence, not a prefix argument.
`C-u', along with other prefix-arg forming keys (e.g., digits) provides a
prefix argument to a command. I don't see those keys as _being_ a prefix
argument. But sure, the two could be identified to some extent, when speaking
loosely.
The doc describes/defines "raw prefix argument" and "numeric prefix argument",
which is the "numeric value" of the raw prefix argument. Those are Lisp values,
which include conses, atoms like `-', and integers. They are not key sequences.
When talking about the key sequences, we (I, at least) distinguish "plain
`C-u'", which provides a prefix arg of `(4)', double plain `C-u', which
provides an arg of `(16)', and so on. Other key sequences provide different raw
prefix args.
I think it could make sense to speak of `C-u', `C-u C-u', `C-u 3 4', `M--',
etc. as "prefix-arg key sequences" or "prefix arg-providing key sequences" or
some such. But I think it would be misleading (except perhaps in certain
contexts where the difference was already made clear) to speak of them as
"prefix arguments".
Just one opinion.
> However, I agree it is clearest NOT to think of C-x RET c
> as a prefix argument. The prefix argument is a specific kind of value
> and that is not how C-x RET c works.
Yes. And in particular (IMO, at least), a prefix arg is a Lisp value - just one
of those values documented as such, which doesn't include (so far) any
key-sequence Lisp values.
I'm not trying to be pedantic. I think it helps users to keep the terminology
clear, here.
It's OK with me if someone providing help to another says, e.g., "use a plain
prefix arg to do XYZ", meaning "use plain `C-u' to do XYZ". That's fine, as
long as both understand what is meant.
But I don't think the Emacs doc should talk that way, in general. It's better
for the doc to keep these things separate - key sequences are not prefix args.
And wrt this discussion, `C-x RET c' is neither a prefix argument nor a key
sequence that provides a prefix arg. IIUC, it has nothing to do with a prefix
arg. It is _not_ like `C-u' or `M--'.
At most, `C-x RET c' could be said to be a key sequence that always precedes
(is always followed by) another key sequence, which it reads.
It's not a _prefix key_, because it's not bound to a keymap. The key sequence
that follows it is not looked up in a map that `C-x RET c' is bound to.
Instead, that following key sequence is read by the command bound to `C-x RET
c', and then invoked. (And `C-x RET c' can set some context for that following
command - bind variables or whatever.)
It's the behavior of a key sequence such as `C-x RET c' (or rather its command)
that's being discussed here. AFAIK, we don't have a name for such key
sequences/commands/behavior. Until now, the only instance of such a thing
(AFAIK) was `C-x RET c'. Now there might be a second: `C-x &'.
Is it perhaps time to come up with some terminology/concepts for this, and to
document it?
And maybe to come up with some constructs that make defining such key
sequences/commands/behavior easier for users?
We added `define-minor-mode' to capture the programming cliche of defining a
minor mode. Perhaps something like that could help here. Dunno whether it would
be jumping the gun or overkill to do that now, since there has been so little
use of the cliche, so far. (I.e., unlike defining a minor mode, it's not really
a cliche yet - just a rarely used technique.)
- RE: Introducing thread-safe Tramp, (continued)
- RE: Introducing thread-safe Tramp, Drew Adams, 2018/08/04
- Re: Introducing thread-safe Tramp, Michael Albinus, 2018/08/04
- RE: Introducing thread-safe Tramp, Drew Adams, 2018/08/04
- Re: Introducing thread-safe Tramp, Michael Albinus, 2018/08/05
- Re: Introducing thread-safe Tramp, Eli Zaretskii, 2018/08/04
- RE: Introducing thread-safe Tramp, Drew Adams, 2018/08/04
- Re: Introducing thread-safe Tramp, Eli Zaretskii, 2018/08/04
- Re: Introducing thread-safe Tramp, Richard Stallman, 2018/08/04
- Re: Introducing thread-safe Tramp, Michael Albinus, 2018/08/05
- Re: Introducing thread-safe Tramp, Richard Stallman, 2018/08/05
- RE: Introducing thread-safe Tramp,
Drew Adams <=
- Re: Introducing thread-safe Tramp, Howard Melman, 2018/08/06
- Re: Introducing thread-safe Tramp, Werner LEMBERG, 2018/08/06
- Re: Introducing thread-safe Tramp, Michael Albinus, 2018/08/06
- Re: Introducing thread-safe Tramp, Clément Pit-Claudel, 2018/08/06
- RE: Introducing thread-safe Tramp, Drew Adams, 2018/08/06
- RE: Introducing thread-safe Tramp, Drew Adams, 2018/08/06
- Re: Introducing thread-safe Tramp, Howard Melman, 2018/08/06
- Re: Introducing thread-safe Tramp, Stefan Monnier, 2018/08/06
- Re: Introducing thread-safe Tramp, Dmitry Gutov, 2018/08/08