RE: Introducing thread-safe Tramp

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

Hm; interesting. Not sure I've seen this kind of thing before.

I don't really think we should call `C-x &' here a "prefix argument", in any case. For one thing, that muddies the waters for each other time we talk about "prefix argument". 

Not sure how we should talk about this.  It's kind of like a prefix key, but its binding is not a keymap but a command that reads a key sequence and invokes that key's command with particular variable binding in effect. 

A command that dispatches to other commands, perhaps binding controlling variables is an old idea. But in this case you've made use of reading a second key sequence, with its own prefix arg, and involved that with the dispatching logic.

If we're going to do this then it really invites generalization, or at least copycat uses with other such kinda-prefix-keys. The handling of a subsequent prefix arg (for the followup command), in particular, seems something generally useful.

And then there's the possibility of, say, using a prefix arg with `C-x &' itself - to do whatever (temporarily turn on a mode, enabling a given keymap for control of the followup key reading,...). Lots of crazy possibilities.

What's the real reason for doing this, as the answer to the question of how to provide keys for async file commands? 

We will now have the variable, which users can set to get or not get async behavior for file commands by default. I questioned whether we should "spend" a prefix argument on flipping the variable value during the use of a particular command. And you pointed out that some commands that we want to be able to give asyncness already use a prefix arg for other things. So using a normal prefix arg was apparently dropped. (Thank you for that.)

But is this the best way to offer users commands/keys that provide both sync and async file commands? 

I suggested just duplicating the existing commands, which lets users themselves define any number of commands that combine pairs of sync/async commands, e.g., letting a prefix arg decide the behavior (one way or the other). E.g., a user can define a `my-find-file' command that uses a prefix arg to do sync/async, and s?he can remap `find-file' to that.

If necessary, Emacs could provide such sync/async pair commands for some or all of the file commands, so users don't need to define them (not that that's hard to do). But should such new commands usurp the keys of the standard commands now, or should we just (for now, at least) let users remap as desired?

Not sure what to think about the `C-x &' proposal. It certainly is interesting, though - seems even generally promising. We've never taken such an approach before, have we (dunno)? Is there a new need? Or is this discovery of a helpful, general new feature? Seems like the latter. (Could be both.) Perhaps this deserves some new terminology and general doc.

(Someone will probably point out that this is nothing special/new, and that I just haven't had enough coffee this morning...)