[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: |
Tue, 24 Jul 2018 08:06:06 -0700 (PDT) |
This sounds like a good feature. I haven't looked at
the code, so I don't really know how it's implemented.
I have one objection to what I think you're proposing
for the design, so far at least.
It's true that `find-file' etc. are commands. They
are also functions that users sometimes call from Lisp.
My a priori objection is the use of a prefix arg to
indicate that you want a separate thread. I would
prefer that users specify this intention in some other
way, and that we reserve the use of a prefix arg for
something else (future).
How else might a user specify use of a separate thread?
Possibilities include:
* Use a different function/command. This is the
usual way Emacs handles such things: new function.
It's what we do for the choice of same/other window,
for example - we have two commands, which can be
bound to two different keys.
* Bind a defvar variable. This is what we do for
respect of `find-file-wildcards', for example.
I'd be OK with either of those approaches, and perhaps
with others. I doubt that I can be in favor of the
prefix-arg approach.
If it were I, I would probably do something like this:
1. Add another optional arg (Boolean), to determine
the behavior. I haven't seen your code, but this
is probably what you've done already.
2. In the body, use that optional arg to override a
defvar variable, which otherwise determines the
behavior (choice).
3. Define additional commands for convenience, which
pass the optional arg (non-nil) to give the
separate-thread behavior.
Any user who wants to combine such a separate command
with the corresponding usual command, and who wants
to use a prefix arg to make the choice, can easily do
so. But Emacs itself will have reserved the ability
to use a prefix arg for something else, and it will
have provided new commands that users can bind to
other keys.
Just one opinion, and open to change. Thanks again
for this feature. Let me know, if I misunderstand
something.
- Re: Introducing thread-safe Tramp, (continued)
- Re: Introducing thread-safe Tramp, Michael Albinus, 2018/07/24
- Re: Introducing thread-safe Tramp, martin rudalics, 2018/07/24
- Re: Introducing thread-safe Tramp, Michael Albinus, 2018/07/25
- Re: Introducing thread-safe Tramp, Eli Zaretskii, 2018/07/25
- Re: Introducing thread-safe Tramp, Eli Zaretskii, 2018/07/25
- Re: Introducing thread-safe Tramp, Michael Albinus, 2018/07/25
- Re: Introducing thread-safe Tramp, martin rudalics, 2018/07/26
- Re: Introducing thread-safe Tramp, Michael Albinus, 2018/07/26
- Re: Introducing thread-safe Tramp, martin rudalics, 2018/07/26
- Re: Introducing thread-safe Tramp, Eli Zaretskii, 2018/07/26
- RE: Introducing thread-safe Tramp,
Drew Adams <=
- Re: Introducing thread-safe Tramp, Michael Albinus, 2018/07/25
- Re: Introducing thread-safe Tramp, Phil Sainty, 2018/07/25
- Re: Introducing thread-safe Tramp, Andreas Schwab, 2018/07/25
- Re: Introducing thread-safe Tramp, Michael Albinus, 2018/07/25
- Re: Introducing thread-safe Tramp, Robert Pluim, 2018/07/25
- Re: Introducing thread-safe Tramp, Michael Albinus, 2018/07/27
- Re: Introducing thread-safe Tramp, Filipp Gunbin, 2018/07/27
- Re: Introducing thread-safe Tramp, Michael Albinus, 2018/07/27
- Re: Introducing thread-safe Tramp, Filipp Gunbin, 2018/07/27
- Re: Introducing thread-safe Tramp, Eli Zaretskii, 2018/07/28