[Top][All Lists]

[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: Sat, 4 Aug 2018 08:42:49 -0700 (PDT)

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 

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 

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

reply via email to

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