Can't override magit-clone settings in vertico-multiform

[matthewbauer]

I'd like to be able to set:

(setq vertico-multiform-commands '((magit-clone (vertico-preselect . prompt))))

so that I can normally use vertico-preselect=directory, but also have vertico-preselect=prompt for magit-clone (no preselection of a newly cloned repo, despite it being a directory).

Unfortunately, magit-clone does not seem to propagate this-comand in the way vertico-multiform would like. this-command is changed to exit-minibuffer on the first magit-clone-read-repository call, and not set back for read-directory-name. Reproduction:

(defun magit-clone-read-repository-example ()
  (interactive)
  (message "first this-command: %s" this-command)
  (magit-clone-read-repository)
  (message "second this-command: %s" this-command)
  (message "current-minibuffer-command: %s" current-minibuffer-command)
  )

gives

first this-command: magit-clone-read-repository-example
Clone from [u]rl or name, [p]ath, [l]ocal url, or [b]undle u
second this-command: exit-minibuffer
current-minibuffer-command: magit-clone-read-repository-example

note second this-command = exit-minibuffer

This is important because it's the second minibuffer call (read-directory-name) that I want to change the behavior for. For reference:

(defun magit-clone-read-args ()
  (let ((repo (magit-clone-read-repository)))
    (list repo
          (read-directory-name
           "Clone to: "
           (if (functionp magit-clone-default-directory)
               (funcall magit-clone-default-directory repo)
             magit-clone-default-directory)
           nil nil
           (magit-clone--url-to-name repo))
          (transient-args 'magit-clone))))

[matthewbauer]

Potential PR fix for reference: #663

[minad]

Thanks for the explanation. I see your point - it would make sense to prefer current-minibuffer-command over this-command, such that the command is stable even for multiple prompts. However for some reason the variable is unreliable - occasionally the variable is nil in the minibuffer-setup-hook, in contrast to this-command and I don't understand why. I could use (or current-minibuffer-command this-command) as a workaround, but I'd like first to understand why this happens.

[matthewbauer]

I could use (or current-minibuffer-command this-command) as a workaround, but I'd like first to understand why this happens.

yep makes sense. i was going to suggest the same thing.

[minad]

It is not clear to me what is wrong, but it looks like an Emacs bug related to the interactive specification:

(defun test-command-bad1 (arg)
  (interactive "P")
  (message "current-minibuffer-command=%S this-command=%S " current-minibuffer-command this-command))

(defun test-command-bad2 (&optional arg)
  (interactive "P")
  (message "current-minibuffer-command=%S this-command=%S " current-minibuffer-command this-command))

(defun test-command-okay1 (&optional arg)
  (interactive)
  (message "current-minibuffer-command=%S this-command=%S " current-minibuffer-command this-command))

(defun test-command-okay2 (arg)
  (interactive
   (list
    (message "current-minibuffer-command=%S this-command=%S " current-minibuffer-command this-command))))

(keymap-global-set "C-c t 1" #'test-command-bad1)
(keymap-global-set "C-c t 2" #'test-command-bad2)
(keymap-global-set "C-c t 3" #'test-command-okay1)
(keymap-global-set "C-c t 4" #'test-command-okay2)

The bad commands report current-minibuffer-command=nil. Can you confirm this? I am on Emacs 31.

[minad]

I asked on the Emacs bug tracker about this: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=80815

[matthewbauer]

yep same behavior here. emacs 30.2