RE: Introducing thread-safe Tramp

[Drew Adams <drew.adams@oracle.com>]

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