emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Introducing thread-safe Tramp


From: Michael Albinus
Subject: Re: Introducing thread-safe Tramp
Date: Wed, 25 Jul 2018 11:46:42 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

Drew Adams <address@hidden> writes:

Hi Drew,

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

I don't understand your reservation. 40+ years of Emacs, and there was
no need yet for a prefix argument of find-file. I would be surprised if
it happens next time.

Running the commands asynchronously is very tight bound to the usual
invocation of the commands, so I don't see that something else, which
might asks for a prefix argument of the commands, will be better suited.

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

It isn't about command names. It is about key bindings. We have all
these bindings 'C-x C-f', 'C-x C-r', 'C-x C-v', 'C-x 4 f', 'C-x 5 f'.
If we don't allow a prefix argument, we need complete new bindings. My
memory muscle tells me I'm too old to learn them.

> * Bind a defvar variable.  This is what we do for
>   respect of `find-file-wildcards', for example.

That's a good idea to visit files asynchronously by default. Maybe we
shall add such user option.

But I don't believe people will always visit files asynchronously. They
will do it for remote files, they will do it for huge files. But for my
daily work with local small files, this would be overkill.

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

All these functions have a new optional argument `threads'.

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

These are not needed I believe for the reasons above.

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

Again, this is based on the assumption we'll need prefix arguments for
something else. I doubt, "something else" will hit us, and if it
happens, that it is better suited to occupy the prefix arg.

> Just one opinion, and open to change.  Thanks again
> for this feature.  Let me know, if I misunderstand
> something.

Same for me. Just my opinion. Let's see what other people say, and what
the maintainers decide.

Best regards, Michael.



reply via email to

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