[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
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...)
- Re: Introducing thread-safe Tramp, (continued)
- Re: Introducing thread-safe Tramp, Eli Zaretskii, 2018/08/07
- Re: Introducing thread-safe Tramp, Michael Albinus, 2018/08/07
- RE: Introducing thread-safe Tramp, Drew Adams, 2018/08/07
- RE: Introducing thread-safe Tramp, Drew Adams, 2018/08/07
- Re: Introducing thread-safe Tramp, Michael Albinus, 2018/08/07
- Re: Introducing thread-safe Tramp, Eli Zaretskii, 2018/08/07
- Re: Introducing thread-safe Tramp, Michael Albinus, 2018/08/08
- Re: Introducing thread-safe Tramp, Filipp Gunbin, 2018/08/08
- Re: Introducing thread-safe Tramp, Stefan Monnier, 2018/08/08
- RE: Introducing thread-safe Tramp, Drew Adams, 2018/08/08
- RE: Introducing thread-safe Tramp,
Drew Adams <=
- Re: Introducing thread-safe Tramp, Michael Albinus, 2018/08/04
- RE: Introducing thread-safe Tramp, Drew Adams, 2018/08/04
- Re: Introducing thread-safe Tramp, Michael Albinus, 2018/08/04
- RE: Introducing thread-safe Tramp, Drew Adams, 2018/08/04
- Re: Introducing thread-safe Tramp, Michael Albinus, 2018/08/05
- Re: Introducing thread-safe Tramp, Eli Zaretskii, 2018/08/04
- RE: Introducing thread-safe Tramp, Drew Adams, 2018/08/04
- Re: Introducing thread-safe Tramp, Eli Zaretskii, 2018/08/04
- Re: Introducing thread-safe Tramp, Richard Stallman, 2018/08/04
- Re: Introducing thread-safe Tramp, Michael Albinus, 2018/08/05