RE: Introducing thread-safe Tramp

[Drew Adams]

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