emacs-devel
[Top][All Lists]
Advanced

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

Re: Introducing thread-safe Tramp


From: Eli Zaretskii
Subject: Re: Introducing thread-safe Tramp
Date: Sat, 04 Aug 2018 21:34:48 +0300

> From: Michael Albinus <address@hidden>
> Cc: address@hidden,  address@hidden,  address@hidden
> Date: Sat, 04 Aug 2018 19:29:50 +0200
> 
> find-file-asynchronously is defined to be file-related (as of now):
> 
> --8<---------------cut here---------------start------------->8---
> Documentation:
> Non-nil means visit file asynchronously when called interactively.
> If it is a regular expression, it must match the file name to be
> visited.  This behavior is toggled by a prefix argument to the
> interactive call.
> --8<---------------cut here---------------end--------------->8---

It's okay for the variable to accept a regexp value, because it allows
to customize the variable once and then benefit from the value for
many invocations.

But "C-x &" affects just the next command, so all you need is for it
to produce a boolean value, and have the next command work
asynchronously or not according to that value.  Which probably means
"C-x &" should not bind find-file-asynchronously, but some other
variable, and that variable had better had a name that is not limited
to file operations, for us to be able to use it with other commands.
Because once we extend "C-x &" to non-file commands, it will not
"know" what command will be invoked after it, so it won't be able to
know it should bind find-file-asynchronously or something else.  It
should therefore bind a variable which affects any command.

> > In any case, why should there be a separate command to force just the
> > file-related commands work asynchronously?
> 
> I don't speak a bout a separate command. I speak about the user option,
> which I have introduced for the find-file family of commands. I believe
> the name find-file-asynchronously is too tight (doesn't cover save-buffer
> and friends), and execute-command-asynchronously is too wide (because it
> shall configure file-related command behavior, with the regexp as value).

For the variable which tailors find-file, save-buffer, etc., I agree
that it should not just say "find-file".
execute-file-commands-asynchronously sounds okay to me.  But that's
just part of the broader issue of invoking commands asynchronously.



reply via email to

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