C-x @

C-x @

[Dave Love]

I think the C-x @ map should be documented (as opposed to just
mentioned once in the manual).

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

[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: C-x &

[Michael Albinus]

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

Hi Drew,

>> And of course, "C-x &" invokes a command. 
>
> Yes. But invoking a command is not being a command.

Yes. I haven't said otherwise, at least in my last email.

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

I haven't said that `C-x &' is any kind of command, at least in my last
email.

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

Again, I haven't said that `C-x &' is a command, in my last email.

Let's agree the obvious: `universal-async-argument' is a command, by
default bound to the key sequences `C-x &' and `M-x  u n i v e r s a l -
a s y n c - a r g u m e n t RET.'

The only raison d'être of `universal-async-argument' is to read another
key sequence, which invokes the command bound to that key sequence. This
means, the command `universal-async-argument' always precedes another
command, which I call a prefix in my understanding. Therefore, I've
proposed to call `universal-async-argument' a "prefix command".

The Emacs manual distinguishes between commands and the key (sequence) a
command is bound to. But it explicitely says, that both could be used
equal:

--8<---------------cut here---------------start------------->8---
   In this manual, we will often speak of keys like ‘C-n’ as commands,
even though strictly speaking the key is bound to a command.
--8<---------------cut here---------------end--------------->8---

See (info "(emacs) Commands")

So it would be also allowed to speak about the key sequence `C-x &' as a
command, but I don't insist on this if it makes you feel bad.

Best regards, Michael.

RE: C-x &

[Drew Adams]

> Yes. I haven't said otherwise, at least in my last email.
> 
> > 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.
> 
> I haven't said that `C-x &' is any kind of command, at least in my last
> email.

Right. You didn't. But some others did. And it wasn't obvious (to me) that you didn't mean to say that `C-x &' is a "prefix command". If you meant only that `universal-sync-argument' is a prefix command then, as I said, that's OK by me. (The doc should then define "prefix 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.
> 
> Again, I haven't said that `C-x &' is a command, in my last email.
> 
> Let's agree the obvious: `universal-async-argument' is a command, by
> default bound to the key sequences `C-x &' and `M-x  u n i v e r s a l -
> a s y n c - a r g u m e n t RET.'

Agreed.

(Although I wouldn't say that the command is bound to `M-x...'. That sequence of keys invokes `u-a-a', but the command is not bound to it. We just don't say that kind of thing in Emacs. The key sequences bound to a command are well defined, and they don't include `M-x' followed by keys spelling out the command name. Similarly, the command is not bound to `M-x uni-a-arg TAB RET' etc.)

> The only raison d'être of `universal-async-argument' is to read another
> key sequence, which invokes the command bound to that key sequence. This
> means, the command `universal-async-argument' always precedes another
> command, which I call a prefix in my understanding. 

Agreed. (Although the command that is preceded by `u-a-a' is, if anything, a suffix of it, not a prefix. I suspect you just misspoke in the last phrase.)

> Therefore, I've proposed to call `universal-async-argument' a "prefix command".

OK by me (where "it" is the command, not `C-x &'). "Prefix command" then needs to be described/defined/explained in the manual.

> The Emacs manual distinguishes between commands and the key (sequence) a
> command is bound to. But it explicitely says, that both could be used
> equal:
> 
> --8<---------------cut here---------------start------------->8---
>    In this manual, we will often speak of keys like ‘C-n’ as commands,
> even though strictly speaking the key is bound to a command.
> --8<---------------cut here---------------end--------------->8---
> 
> See (info "(emacs) Commands")

Yeah. I was afraid someone might quote that passage. ;-) 

I don't have a problem with that text, because its purpose is to state that we sometimes speak that way even though it is not really correct. It's not defining a key sequence as the command that it's bound to - quite the opposite. It both (1) points out that a key sequence is not the same thing as the command that it's bound to and (2) mentions that sometimes we gloss over that difference, for brevity and when the context makes the meaning clear.

> So it would be also allowed to speak about the key sequence `C-x &' as a
> command, but I don't insist on this if it makes you feel bad.

It would be allowed to say "command `C-x &'", yes, for brevity. That's a far cry from defining a new term "prefix command" and applying it to `C-x &'. (Especially since there is also a notion of prefix key, which is something quite different.)

In sum, I don't have a problem with calling `universal-async-argument' a "prefix command", if that term is defined in the manual.

----

About the command name (FWIW):

I'm not crazy about the name "universal-async-argument'. I realize that it's modeled on `universal-argument', and I can live with it. But I wish that both of those commands were named differently. (No, I'm not proposing a name change for `u-a' at this late date.)

`u-a-a' doesn't necessarily provide a (non-default) prefix arg to a command. It invokes a command (bound to a key sequence that it reads).

It's somewhat akin to `execute-extended-command' or `comint-redirect-send-command'. Those read a command name and not a key sequence, so in that respect they differ. But I think it might be better for `u-a-a' to be named `<something>-command', where <something> does not suggest "universal argument".

Unlike `u-a', you need not provide a prefix arg to `u-a-a'. It's not really the same kind of command. `u-a-a' does accept and take into account a prefix arg, if you provide one; but it's not required (IIUC). (Maybe I'm wrong about this. What prefix arg does bare `C-x &' provide? Does it provide `(4)', as `C-u' does?

No, I don't feel strongly about the command name. Yes, I understand why you proposed "universal-async-argument". But I think its association with `universal-argument' confuses more than clarifies. No, I don't have a great suggestion for the command name. Ideally it should convey "read a key sequence and invoke the command bound to it" (and the doc string would explain that it will also read a prefix arg and pass that to the command). Maybe `invoke-command-bound-to' or some such.

RE: C-x &

[Drew Adams]

> No, I don't feel strongly about the command name. Yes, I understand why
> you proposed "universal-async-argument". But I think its association with
> `universal-argument' confuses more than clarifies. No, I don't have a great
> suggestion for the command name. Ideally it should convey "read a key
> sequence and invoke the command bound to it" (and the doc string would
> explain that it will also read a prefix arg and pass that to the command).
> Maybe `invoke-command-bound-to' or some such.

Sorry; I meant to mention asynchronous execution.

> Ideally it should convey "read a key
> sequence and invoke the command bound to it

, in an asynchronous way"

> (and the doc string would
> explain that it will also read a prefix arg and pass that to the command).
> Maybe `invoke-command-bound-to' or some such.

But the command name should have `async' in it, somewhere.

Re: C-x &

[Michael Albinus]

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

>> No, I don't feel strongly about the command name. Yes, I understand why
>> you proposed "universal-async-argument". But I think its association with
>> `universal-argument' confuses more than clarifies. No, I don't have a great
>> suggestion for the command name. Ideally it should convey "read a key
>> sequence and invoke the command bound to it" (and the doc string would
>> explain that it will also read a prefix arg and pass that to the command).
>> Maybe `invoke-command-bound-to' or some such.
>
> Sorry; I meant to mention asynchronous execution.

The name "universal-async-argument" was inherited from
"universal-coding-system-argument", which implements a similar technique.

>> Ideally it should convey "read a key
>> sequence and invoke the command bound to it
>
> , in an asynchronous way"
>
>> (and the doc string would
>> explain that it will also read a prefix arg and pass that to the command).
>> Maybe `invoke-command-bound-to' or some such.
>
> But the command name should have `async' in it, somewhere.

"universal-async-argument" has it. And until we have a better name, I'd
like to keep it. It will be easy to replace the name by another one if
needed, and it isn't user visible in general.

Best regards, Michael.

Re: C-x &

[Michael Albinus]

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

>> I haven't said that `C-x &' is any kind of command, at least in my last
>> email.
>
> Right. You didn't. But some others did. And it wasn't obvious (to me)
> that you didn't mean to say that `C-x &' is a "prefix command". If you
> meant only that `universal-sync-argument' is a prefix command then, as
> I said, that's OK by me. (The doc should then define "prefix
> command".)
>
>> Again, I haven't said that `C-x &' is a command, in my last email.
>> 
>> Let's agree the obvious: `universal-async-argument' is a command, by
>> default bound to the key sequences `C-x &' and `M-x  u n i v e r s a l -
>> a s y n c - a r g u m e n t RET.'
>
> Agreed.
>
> (Although I wouldn't say that the command is bound to `M-x...'. That
> sequence of keys invokes `u-a-a', but the command is not bound to
> it. We just don't say that kind of thing in Emacs. The key sequences
> bound to a command are well defined, and they don't include `M-x'
> followed by keys spelling out the command name. Similarly, the command
> is not bound to `M-x uni-a-arg TAB RET' etc.)
>
>> The only raison d'être of `universal-async-argument' is to read another
>> key sequence, which invokes the command bound to that key sequence. This
>> means, the command `universal-async-argument' always precedes another
>> command, which I call a prefix in my understanding. 
>
> Agreed. (Although the command that is preceded by `u-a-a' is, if
> anything, a suffix of it, not a prefix. I suspect you just misspoke in
> the last phrase.)
>
>> Therefore, I've proposed to call `universal-async-argument' a
>> "prefix command".
>
> OK by me (where "it" is the command, not `C-x &'). "Prefix command"
> then needs to be described/defined/explained in the manual.

OMG: we are in violent agreement :-)

>> The Emacs manual distinguishes between commands and the key (sequence) a
>> command is bound to. But it explicitely says, that both could be used
>> equal:
>> 
>> --8<---------------cut here---------------start------------->8---
>>    In this manual, we will often speak of keys like ‘C-n’ as commands,
>> even though strictly speaking the key is bound to a command.
>> --8<---------------cut here---------------end--------------->8---
>> 
>> See (info "(emacs) Commands")
>
> Yeah. I was afraid someone might quote that passage. ;-) 

That's because of *you* - you have forced me to consult the manual about.

> I don't have a problem with that text, because its purpose is to state
> that we sometimes speak that way even though it is not really
> correct. It's not defining a key sequence as the command that it's
> bound to - quite the opposite. It both (1) points out that a key
> sequence is not the same thing as the command that it's bound to and
> (2) mentions that sometimes we gloss over that difference, for brevity
> and when the context makes the meaning clear.
>
>> So it would be also allowed to speak about the key sequence `C-x &' as a
>> command, but I don't insist on this if it makes you feel bad.
>
> It would be allowed to say "command `C-x &'", yes, for brevity. That's
> a far cry from defining a new term "prefix command" and applying it to
> `C-x &'. (Especially since there is also a notion of prefix key, which
> is something quite different.)
>
> In sum, I don't have a problem with calling `universal-async-argument'
> a "prefix command", if that term is defined in the manual.

Agreed.

Best regards, Michael.