C-x & (was: Introducing thread-safe Tramp)

C-x & (was: Introducing thread-safe Tramp)

[Drew Adams]

> > As Richard suggested, don't call it anything. At least do not call it any of
> > those things (it's not a command or a prefix key (sequence)).
> 
> It's definitely a command and it is used before another, so "prefix
> command" sounds about right.

`C-x &' is definitely _not_ a command.

If you want to call the command it's bound to (by default) a "prefix command", that's a different story. But a key sequence is not a command. It might be bound to a command, but it's not a command.

And if a user replaces that key binding by a different one then the command continues to have the same behavior ("prefix command" behavior, if you like), but the key sequence no longer has that behavior.

Introducing thread-safe Tramp

[Michael Albinus]

Hi,

I have created a new branch feature/tramp-thread-safe. The major change
is making Tramp thread-safe, that means, several basic file operations
can run concurrently now.

Being a library, Tramp does not create new threads on its own. This must
be performed by the callers.

I have changed the `find-file' family of commands to raise their
underlying file operations asynchronously if indicated. Every visiting
of a file happens in its own thread then. If wildcards are used, one
thread per involved file is created.

In order to enable this, the respective command must be called with a
prefix argument, like "C-u C-x C-f ...".  Emacs will remain responsive,
you can continue with whatever operation. This will be best seen with
remote files, because they need more time to load into a buffer. Emacs
is not as responsive yet as I hoped to achieve; further optimization is
needed.

As second change, I have modified `vc-refresh-state' to run always in
its own thread. This is because I have observed, that for git
repositories, loading a remote file is often much faster than the
following update of its state in the modeline. For the time being this
behaviour is hard-coded, I haven't seen any drawback for this even for
local files. But we could trigger it also via a user option.

@Dmitry?

Please give it as much testing as possible. I cannot promise Emacs won't
crash ever with these changes, so it is not time for production
systems. But all bug reports and feedbacks will help to improve this new
feature.

And, if there are not too serious complaints, I will merge it into
master after a while :-) You are warned!

Best regards, Michael.

Re: Introducing thread-safe Tramp

[Michael Albinus]

Filipp Gunbin <fgunbin@fastmail.fm> writes:

> I don't like prefix arg, too.  It feels like prefix arg should change
> the user-visible behaviour of the command, and running asynchronously
> feels more like a technical detail, though important one.

It is user-visible. If you visit a file asynchronously, Emacs is still
responsive, and you can run other commands. For example, during
asynchronous loading of /ssh::~/src/emacs/admin/* I was still able to
call gnus and read my emails.

> Maybe there could be rules for find-file to use async behavior by
> default, like:
>
> - When a non-local method is explicitly used (that is, not /sudo)
>
> - When default-directory is on a remote host
>
> - When a file being visited is greater than some customizable size

I was thinking already about. find-file-asynchronously could be a regexp
or a function, determining whether a file should be visited
asynchronously, or not.

> - When a special command was given before (analogy with `C-x RET c' was
> already mentioned here).  That special command by default could "toggle
> default".  It could accept prefix arg, say C-u for "force sync" and C-u
> C-u for "force async".  That way sync/async preference will be decoupled
> from the actual command, and could be added to any other command in the
> future.

I will play with these proposals.

Best regards, Michael.

Re: Introducing thread-safe Tramp

[Michael Albinus]

Michael Albinus <michael.albinus@gmx.de> writes:

>> - When a special command was given before (analogy with `C-x RET c' was
>> already mentioned here).  That special command by default could "toggle
>> default".  It could accept prefix arg, say C-u for "force sync" and C-u
>> C-u for "force async".  That way sync/async preference will be decoupled
>> from the actual command, and could be added to any other command in the
>> future.
>
> I will play with these proposals.

As you have seen the other mail, I'm using now C-u to toggle the default
value of find-file-asynchronously. I'm open for any other key binding,
but C-u has the advantage that it works for both "C-u C-x C-f ..." and
"C-u M-x find-file ..." and friends.

Best regards, Michael.

RE: Introducing thread-safe Tramp

[Drew Adams]

> >> - When a special command was given before (analogy with `C-x RET c' was
> >> already mentioned here).  That special command by default could "toggle
> >> default".  It could accept prefix arg, say C-u for "force sync" and C-u
> >> C-u for "force async".  That way sync/async preference will be decoupled
> >> from the actual command, and could be added to any other command in
> the
> >> future.
> >
> > I will play with these proposals.
> 
> As you have seen the other mail, I'm using now C-u to toggle the default
> value of find-file-asynchronously. I'm open for any other key binding,
> but C-u has the advantage that it works for both "C-u C-x C-f ..." and
> "C-u M-x find-file ..." and friends.

(Don't you mean that `C-u' simply toggles `find-file-asynchronously' - its current value, not its default value?)

As mentioned, I don't think it's a good idea to spend/waste the use of a prefix arg on this. (Just one opinion.) To me, it doesn't matter so much that such commands are longstanding and we haven't yet seen competing requests for prefix-arg behavior.

But if that's the way this will be done (`C-u' toggles ` find-file-asynchronously') then please consider this instead: Don't co-opt the use of an arbitrary prefix arg; instead, do what you propose only for `C-u C-u' (double plain prefix arg). That will make it much easier to accommodate other uses of (other) prefix args in the future.

Re: Introducing thread-safe Tramp

[Michael Albinus]

Drew Adams <drew.adams@oracle.com> writes:

Hi Drew,

>> As you have seen the other mail, I'm using now C-u to toggle the default
>> value of find-file-asynchronously. I'm open for any other key binding,
>> but C-u has the advantage that it works for both "C-u C-x C-f ..." and
>> "C-u M-x find-file ..." and friends.
>
> (Don't you mean that `C-u' simply toggles `find-file-asynchronously' -
> its current value, not its default value?)

Of course.

> As mentioned, I don't think it's a good idea to spend/waste the use of
> a prefix arg on this. (Just one opinion.) To me, it doesn't matter so
> much that such commands are longstanding and we haven't yet seen
> competing requests for prefix-arg behavior.
>
> But if that's the way this will be done (`C-u' toggles `
> find-file-asynchronously') then please consider this instead: Don't
> co-opt the use of an arbitrary prefix arg; instead, do what you
> propose only for `C-u C-u' (double plain prefix arg). That will make
> it much easier to accommodate other uses of (other) prefix args in the
> future.

If nobody objects, I could do this. However, during the discussion it
was proposed to find a common indication for asynchronous file
operations.

`C-u C-u' will work for the `find-file' family of commands, but it
doesn't work for `save-buffer', which uses already `C-u', `C-u C-u',
`C-u C-u C-u' and `C-u 0'.

Best regards, Michael.

Re: Introducing thread-safe Tramp

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Date: Mon, 30 Jul 2018 10:44:07 +0200
> Cc: Filipp Gunbin <fgunbin@fastmail.fm>, emacs-devel@gnu.org
> 
> If nobody objects, I could do this. However, during the discussion it
> was proposed to find a common indication for asynchronous file
> operations.
> 
> `C-u C-u' will work for the `find-file' family of commands, but it
> doesn't work for `save-buffer', which uses already `C-u', `C-u C-u',
> `C-u C-u C-u' and `C-u 0'.

Indeed.  So I think the case for having a new prefix command akin to
"C-x RET c" becomes stronger and stronger.

Re: Introducing thread-safe Tramp

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

>> If nobody objects, I could do this. However, during the discussion it
>> was proposed to find a common indication for asynchronous file
>> operations.
>> 
>> `C-u C-u' will work for the `find-file' family of commands, but it
>> doesn't work for `save-buffer', which uses already `C-u', `C-u C-u',
>> `C-u C-u C-u' and `C-u 0'.
>
> Indeed.  So I think the case for having a new prefix command akin to
> "C-x RET c" becomes stronger and stronger.

What about the appended patch for the feature/tramp-thread-safe branch?
It introduces "C-x &" as prefix argument, toggling the meaning of
the `find-file-asynchronously' variable.

Best regards, Michael.

Re: Introducing thread-safe Tramp

[Michael Albinus]

[-- Attachment #1: Type: text/plain, Size: 277 bytes --]

Michael Albinus <michael.albinus@gmx.de> writes:

> What about the appended patch for the feature/tramp-thread-safe branch?
> It introduces "C-x &" as prefix argument, toggling the meaning of
> the `find-file-asynchronously' variable.

Now with patch.

Best regards, Michael.


[-- Attachment #2: Type: text/plain, Size: 5404 bytes --]

diff --git a/doc/emacs/files.texi b/doc/emacs/files.texi
index 46e64c2a27..e4a1369a74 100644
--- a/doc/emacs/files.texi
+++ b/doc/emacs/files.texi
@@ -250,7 +250,7 @@ Visiting
 @end group
 @end example
 
-  With a prefix argument @kbd{C-u}, the meaning of
+  With a prefix argument @kbd{C-x &}, the meaning of
 @code{find-file-asynchronously} will be reverted.  If this user option
 is @code{nil}, visiting a file is performed asynchronously.  Contrary,
 if this user option is non-@code{nil}, visiting a file is performed
diff --git a/doc/lispref/files.texi b/doc/lispref/files.texi
index 9faa47b455..54737ebe64 100644
--- a/doc/lispref/files.texi
+++ b/doc/lispref/files.texi
@@ -119,7 +119,7 @@ Visiting Functions
 If @var{async} is non-@code{nil}, the file will be loaded into the
 buffer asynchronously.  Interactively, this is indicated by either
 setting user option @code{find-file-asynchronously} to non-@code{nil},
-or by a prefix argument.
+or by a prefix argument @kbd{C-x &}.
 
 When @code{find-file} is called interactively, it prompts for
 @var{filename} in the minibuffer.
@@ -232,8 +232,8 @@ Visiting Functions
 If this variable is non-@code{nil}, a file will be visited
 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 of the file
-visiting command.
+is toggled by a prefix argument @kbd{C-x &} to the interactive call of
+the file visiting command.
 @end defopt
 
 @defopt find-file-hook
diff --git a/lisp/files.el b/lisp/files.el
index 195694a7b6..ccdbaeb315 100644
--- a/lisp/files.el
+++ b/lisp/files.el
@@ -1576,14 +1576,56 @@ minibuffer-with-setup-hook
              ,@body)
          (remove-hook 'minibuffer-setup-hook ,hook)))))
 
+(defun universal-file-visiting-argument (async)
+  "Execute a file visiting or saving command using the ASYNC argument.
+See `find-file-asynchronously' for valid values of ASYNC."
+  (interactive
+   (list (and (featurep 'threads) (not find-file-asynchronously))))
+  (let* ((find-file-asynchronously async)
+         (keyseq (read-key-sequence (format "Command to visit or save file:")))
+	 (cmd (key-binding keyseq))
+	 prefix)
+    ;; `read-key-sequence' ignores quit, so make an explicit check.
+    ;; Like many places, this assumes quit == C-g, but it need not be.
+    (if (equal last-input-event ?\C-g)
+	(keyboard-quit))
+    (when (memq cmd '(universal-argument digit-argument))
+      (call-interactively cmd)
+
+      ;; Process keys bound in `universal-argument-map'.
+      (while (progn
+	       (setq keyseq (read-key-sequence nil t)
+		     cmd (key-binding keyseq t))
+	       (not (eq cmd 'universal-argument-other-key)))
+	(let ((current-prefix-arg prefix-arg)
+	      ;; Have to bind `last-command-event' here so that
+	      ;; `digit-argument', for instance, can compute the
+	      ;; prefix arg.
+	      (last-command-event (aref keyseq 0)))
+	  (call-interactively cmd)))
+
+      ;; This is the final call to `universal-argument-other-key', which
+      ;; set's the final `prefix-arg.
+      (let ((current-prefix-arg prefix-arg))
+	(call-interactively cmd))
+
+      ;; Read the command to execute with the given prefix arg.
+      (setq prefix prefix-arg
+	    keyseq (read-key-sequence nil t)
+	    cmd (key-binding keyseq)))
+
+    (let ((current-prefix-arg prefix))
+      (message "")
+      (call-interactively cmd))))
+
+(define-key ctl-x-map "&" 'universal-file-visiting-argument)
+
 (defun find-file-read-args (prompt mustmatch &optional wildcards)
   "Return the interactive spec (<filename> <async>).
 If WILDCARDS is non-nil, return the spec (<filename> t <async>)."
   (let ((filename (read-file-name prompt nil default-directory mustmatch))
-        (async (and (xor find-file-asynchronously current-prefix-arg)
-                    (featurep 'threads))))
-    (when (and async (stringp find-file-asynchronously))
-      (setq async (string-match-p find-file-asynchronously filename)))
+        (async (and (featurep 'threads) find-file-asynchronously)))
+    (when (stringp async) (setq async (string-match-p async filename)))
     (if wildcards `(,filename t ,async) `(,filename ,async))))
 
 (defmacro find-file-with-threads (filename async &rest body)
@@ -1794,8 +1836,8 @@ find-alternate-file-other-window
        (list (read-file-name
 	      "Find alternate file: " file-dir nil
               (confirm-nonexistent-file-or-buffer) file-name)
-	     t (and (xor find-file-asynchronously current-prefix-arg)
-                    (featurep 'threads))))))
+	     t (and (featurep 'threads) find-file-asynchronously)))))
+  (when (stringp async) (setq async (string-match-p async filename)))
   (if (one-window-p)
       (find-file-other-window filename wildcards async)
     (save-selected-window
@@ -1839,8 +1881,8 @@ find-alternate-file
      (list (read-file-name
 	    "Find alternate file: " file-dir nil
             (confirm-nonexistent-file-or-buffer) file-name)
-	   t (and (xor find-file-asynchronously current-prefix-arg)
-                  (featurep 'threads)))))
+	   t (and (featurep 'threads) find-file-asynchronously))))
+  (when (stringp async) (setq async (string-match-p async filename)))
   (unless (run-hook-with-args-until-failure 'kill-buffer-query-functions)
     (user-error "Aborted"))
   (and (buffer-modified-p) buffer-file-name

Re: Introducing thread-safe Tramp

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: drew.adams@oracle.com,  fgunbin@fastmail.fm,  emacs-devel@gnu.org
> Date: Sat, 04 Aug 2018 14:49:35 +0200
> 
> Michael Albinus <michael.albinus@gmx.de> writes:
> 
> > What about the appended patch for the feature/tramp-thread-safe branch?
> > It introduces "C-x &" as prefix argument, toggling the meaning of
> > the `find-file-asynchronously' variable.
> 
> Now with patch.

The command's name should be more general, as I believe this was
envisaged to eventually become effective for more commands than those
which visit files?

> +    ;; `read-key-sequence' ignores quit, so make an explicit check.
> +    ;; Like many places, this assumes quit == C-g, but it need not be.
> +    (if (equal last-input-event ?\C-g)

Why not use current-input-mode here?

> +      ;; This is the final call to `universal-argument-other-key', which
> +      ;; set's the final `prefix-arg.
            ^^^^^
"sets"

Thanks.

Re: Introducing thread-safe Tramp

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

Hi Eli,

>> What about the appended patch for the feature/tramp-thread-safe branch?
>> It introduces "C-x &" as prefix argument, toggling the meaning of
>> the `find-file-asynchronously' variable.
>
> The command's name should be more general, as I believe this was
> envisaged to eventually become effective for more commands than those
> which visit files?

I'm bad in finding good names. What is the superset of "file visiting
and saving"?

>> +    ;; `read-key-sequence' ignores quit, so make an explicit check.
>> +    ;; Like many places, this assumes quit == C-g, but it need not be.
>> +    (if (equal last-input-event ?\C-g)
>
> Why not use current-input-mode here?

Well, I've stolen the code from `universal-coding-system-argument' :-)
Will adapt it in my patch, and also in `universal-coding-system-argument'
in master.

>> +      ;; This is the final call to `universal-argument-other-key', which
>> +      ;; set's the final `prefix-arg.
>             ^^^^^
> "sets"

Ditto.

> Thanks.

Best regards, Michael.

Re: Introducing thread-safe Tramp

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: drew.adams@oracle.com,  fgunbin@fastmail.fm,  emacs-devel@gnu.org
> Date: Sat, 04 Aug 2018 17:12:50 +0200
> 
> >> What about the appended patch for the feature/tramp-thread-safe branch?
> >> It introduces "C-x &" as prefix argument, toggling the meaning of
> >> the `find-file-asynchronously' variable.
> >
> > The command's name should be more general, as I believe this was
> > envisaged to eventually become effective for more commands than those
> > which visit files?
> 
> I'm bad in finding good names. What is the superset of "file visiting
> and saving"?

I was actually thinking about something like universal-async-argument,
entirely unrelated to files etc.

Thanks.

Re: Introducing thread-safe Tramp

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

>> > The command's name should be more general, as I believe this was
>> > envisaged to eventually become effective for more commands than those
>> > which visit files?
>> 
>> I'm bad in finding good names. What is the superset of "file visiting
>> and saving"?
>
> I was actually thinking about something like universal-async-argument,
> entirely unrelated to files etc.

OK, But I also miss a better name for the `find-file-asynchronously'
user option.

> Thanks.

Best regards, Michael.

Re: Introducing thread-safe Tramp

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: drew.adams@oracle.com,  fgunbin@fastmail.fm,  emacs-devel@gnu.org
> Date: Sat, 04 Aug 2018 17:58:37 +0200
> 
> >> I'm bad in finding good names. What is the superset of "file visiting
> >> and saving"?
> >
> > I was actually thinking about something like universal-async-argument,
> > entirely unrelated to files etc.
> 
> OK, But I also miss a better name for the `find-file-asynchronously'
> user option.

execute-command-asynchronously?

(I'm also bad in coming up with good names.)

Re: Introducing thread-safe Tramp

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

>> OK, But I also miss a better name for the `find-file-asynchronously'
>> user option.
>
> execute-command-asynchronously?

Sounds too general to me, because it is about *file* visiting and saving.

execute-file-command-asynchronously?

Re: Introducing thread-safe Tramp

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: drew.adams@oracle.com,  fgunbin@fastmail.fm,  emacs-devel@gnu.org
> Date: Sat, 04 Aug 2018 18:18:06 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> OK, But I also miss a better name for the `find-file-asynchronously'
> >> user option.
> >
> > execute-command-asynchronously?
> 
> Sounds too general to me, because it is about *file* visiting and saving.
> 
> execute-file-command-asynchronously?

But I _wanted_ it to be general, far beyond just file-related
commands.  I though that was what was being discussed: to have a
convenient way of running a command, any command that supported it,
asynchronously.  Was I mistaken?

In any case, why should there be a separate command to force just the
file-related commands work asynchronously?

Re: Introducing thread-safe Tramp

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

>> >> OK, But I also miss a better name for the `find-file-asynchronously'
>> >> user option.
>> >
>> > execute-command-asynchronously?
>> 
>> Sounds too general to me, because it is about *file* visiting and saving.
>> 
>> execute-file-command-asynchronously?
>
> But I _wanted_ it to be general, far beyond just file-related
> commands.  I though that was what was being discussed: to have a
> convenient way of running a command, any command that supported it,
> asynchronously.  Was I mistaken?

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

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

Best regards, Michael.

Re: Introducing thread-safe Tramp

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: drew.adams@oracle.com,  fgunbin@fastmail.fm,  emacs-devel@gnu.org
> 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.

Re: Introducing thread-safe Tramp

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

Hi Eli,

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

Nobody hinders us to bind several variables in
universal-async-argument. For the time being it toggles the value of
execute-file-commands-asynchronously, but this could be extended.

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

I've changed it accordingly. Pushed to the feature/tramp-thread-safe
branch, in order to have the same code basis we're speaking about.

Best regards, Michael.

Re: Introducing thread-safe Tramp

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: drew.adams@oracle.com,  fgunbin@fastmail.fm,  emacs-devel@gnu.org
> Date: Sun, 05 Aug 2018 11:51:34 +0200
> 
> > 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.
> 
> Nobody hinders us to bind several variables in
> universal-async-argument.

If that produces expected results in practice, that'd be fine, yes.

> > 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.
> 
> I've changed it accordingly. Pushed to the feature/tramp-thread-safe
> branch, in order to have the same code basis we're speaking about.

Thanks.

Re: Introducing thread-safe Tramp

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

Hi Eli,

>> > 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.
>> 
>> Nobody hinders us to bind several variables in
>> universal-async-argument.
>
> If that produces expected results in practice, that'd be fine, yes.

I've slept another night over this, and I believe you are right. I've
pushed a patch to the branch, that the universal-async-argument function
toggles the universal-async-argument variable, and binds it before
calling the following command. This is more general, and other commands
but the file visiting ones would profit also from this mechanism w/o
touching universal-async-argument, again.

This needs to be documented better in the Elisp manual, but first we
shall agree how to call this technique. "Prefix argument" is out of the
game. Maybe "prefix command"? Or "prefix sequence", as proposed in this
thread?

Best regards, Michael.

RE: Introducing thread-safe Tramp

[Drew Adams]

> This needs to be documented better in the Elisp manual, but first we
> shall agree how to call this technique. "Prefix argument" is out of the
> game. Maybe "prefix command"? Or "prefix sequence", as proposed in this
> thread?

As Richard suggested, don't call it anything. At least do not call it any of those things (it's not a command or a prefix key (sequence)).

We can, if you want, have a separate discussion, taking our time, to decide whether and what to name this.

C-x & (was: Introducing thread-safe Tramp)

[Michael Albinus]

Drew Adams <drew.adams@oracle.com> writes:

Hi Drew,

>> This needs to be documented better in the Elisp manual, but first we
>> shall agree how to call this technique. "Prefix argument" is out of the
>> game. Maybe "prefix command"? Or "prefix sequence", as proposed in this
>> thread?
>
> As Richard suggested, don't call it anything. At least do not call it
> any of those things (it's not a command or a prefix key (sequence)).

I'm all for an agreement. But until now I hear only how to NOT call
it. I'd prefer to see a counter proposal.

And of course, "C-x &" invokes a command. This is equivalent to "M-x
universal-async-argument". So I don't see what's wrong with "prefix
command" - it is a command which precedes another command.

> We can, if you want, have a separate discussion, taking our time, to
> decide whether and what to name this.

Subject adapted.

Best regards, Michael.

RE: C-x & (was: Introducing thread-safe Tramp)

[Drew Adams]

> And of course, "C-x &" invokes a command. 

Yes. But invoking a command is not being a command.

> This is equivalent to "M-x universal-async-argument". 

Presumably you mean that using key sequence `C-x &' is equivalent to using `M-x universal-async-argument'. That's another way of saying that `C-x &' invokes command `universal-async-argument'.

If you wanted to call command `universal-async-argument' a "prefix command" you could do so. But `C-x &' is not a prefix command or any other kind of command.

> So I don't see what's wrong with "prefix command" - it is a command which precedes another command.

Command `universal-async-argument', when invoked, precedes invocation of the command bound to the key sequence read by `universal-asyn-argument'. Yes.

And using `C-x &' precedes reading of that second key sequence. But neither of those things make `C-x &' into a command, prefix, postfix, or *fix.

> > We can, if you want, have a separate discussion, taking our time, to
> > decide whether and what to name this.
> 
> Subject adapted.

Thx.

Re: Introducing thread-safe Tramp

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: drew.adams@oracle.com,  fgunbin@fastmail.fm,  emacs-devel@gnu.org
> Date: Mon, 06 Aug 2018 12:54:07 +0200
> 
> This needs to be documented better in the Elisp manual, but first we
> shall agree how to call this technique. "Prefix argument" is out of the
> game. Maybe "prefix command"? Or "prefix sequence", as proposed in this
> thread?

My favorite so far is "prefix command".

Thanks.

C-x & (was: Introducing thread-safe Tramp)

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

>> This needs to be documented better in the Elisp manual, but first we
>> shall agree how to call this technique. "Prefix argument" is out of the
>> game. Maybe "prefix command"? Or "prefix sequence", as proposed in this
>> thread?
>
> My favorite so far is "prefix command".

So we are two - see my other message I've just sent, before reading your
message.

> Thanks.

Best regards, Michael.