[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 15:41:36 -0700 (PDT) |
> > 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...)
- Re: Introducing thread-safe Tramp, (continued)
- 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, 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/04
- RE: Introducing thread-safe Tramp,
Drew Adams <=
- 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
- Re: Introducing thread-safe Tramp, Richard Stallman, 2018/08/05
- RE: Introducing thread-safe Tramp, Drew Adams, 2018/08/05
- Re: Introducing thread-safe Tramp, Howard Melman, 2018/08/06
- Re: Introducing thread-safe Tramp, Werner LEMBERG, 2018/08/06