RE: Introducing thread-safe Tramp

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

> > You didn't answer wrt why we shouldn't just define additional commands
> > and let users create async/sync toggle commands using them (and
> > binding them to the same muscle-memory keys), or why we shouldn't also
> > create such toggle commands (toggling with a prefix arg), but not
> > necessarily bind them to the standard keys right away. IOW, what we
> > usually do.
> 
> Because I believe this is more convenient. 

I understand that you feel that. Why not find that out from users, over a period of time? If users end up binding the toggle commands I described, in place of the traditional file-operation bindings, then we'll know just how important and convenient such dispatching is. If only some users do that, and with only one or a couple of the file commands, then we'll have info to direct how best to accommodate that need.

Just a suggestion.

> It is common practice to change the behavior of a command by a prefix, 

What does "a prefix" even mean, here? What's prefixing what?

It's common practice to sometimes change command behavior according to a _prefix argument_. There's no prefix argument involved here (except possibly before the second key sequence - the one that is read by `C-x &'). Certainly `C-x &' is not, itself, a prefix argument. 

Nor is there any _prefix key_ involved here. `C-x &' is not bound to a keymap. I don't see how `C-x &' is a prefix <anything>.

And I don't see any common practice involved here. Rather, there is only one such use case I'm aware of: `C-x RET c'.

> and this is what "C-x &" is good for. It *is* a prefix; 

Again, what does "a prefix" even mean? `C-x &' is a key sequence. What is it a prefix of? It's not a _prefix key_ (it's not bound to a keymap). What can a key sequence be a prefix of, if not of a set of key sequences, if it is not a prefix key? 

`C-x &' is a key sequence that's bound to a command that reads a key sequence and invokes that second key sequence's command. And when reading the key sequence it allows use of prefix argument. But in what way is key sequence `C-x &' a "prefix" of something - what's that something that it prefixes?

If I type the key `a' and then I type the key `b', `a' is not a prefix of `b' in any usual sense. The behavior you have does not fit any of the current uses of the word "prefix" in Emacs jargon/doc, I think.

If you try to think of `C-x &' as some (new) kind of "prefix" then please start by saying what it is a prefix of.

> just the implementation varies.

Implementation of what? The answer, from your statement, can only be "a prefix". But implementation of a prefix of what? What is this "a prefix" you speak of?

> > Right. But this is still a new use case, I think. The `C-x RET c' case
> > is pretty much the only other use of this technique, AFAIK.
> >
> > We document the use of prefix keys, i.e., binding a key to a
> > keymap. We don't document this technique/cliche. Perhaps we should.
> 
> Agreed. Now, we have two special cases. I agree also with you to make
> this technique more general, but since I'm in the muddy waters of
> threads, I'd like to postpone it a bit (or somebody else does). If we
> have the more general approach, it deserves documentation.

Sounds good. Thanks for working on the threading feature. Sounds very good.

I don't think this technique / programming cliche (used for `C-x RET c' and proposed for `C-x &') should be passed off as somehow using a different kind of prefix argument - no connection, IMO. Nor should the key sequence involved be shoehorned into consideration as a prefix key. It's neither.

I don't see any useful use of the word "prefix" here, but if there is one then it needs to be defined explicitly, as some new kind of prefixing (starting by saying what gets prefixed).

I think we agree that this technique/cliche is interesting and could be applied more widely by users (other use cases) or turned into something more general (making it easy for users to take advantage of, for their own key-reading commands, without going through the same implementation cliche explicitly).

One could even imagine (similarly to a prefix key whose keymap binding has one or more prefix keys) applying the technique more than once in succession: a command that reads a key sequence (possibly with prefix arg) being itself read by a command that reads a key sequence (possibly with prefix arg).

Whereas it is simple to move a keymap around, binding it to this or that prefix key (any of which might itself be in a keymap that is bound to a prefix key...), it's a bit more cumbersome (less modular) to combine things and move them around with the technique in question. 

It's about defining a particular kind of command. Perhaps some good new programming constructs can be found, to help out here. Maybe a command-defining macro, to bundle up the technique nicely. Or maybe we're hinting at a variant of or a new form for a keymap. 

(Another thing that comes to (my) mind here, for some reason, are hydras...)