emacs-devel
[Top][All Lists]
Advanced

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]