vertico-buffer--restore not getting called?

[dgillis]

While using vertico-buffer-mode I've noticed my windows ending up in a state where they cannot be deleted which I believe is a result of these parameters set inside vertico-buffer-setup here:

    (set-window-parameter win 'no-other-window t)
    (set-window-parameter win 'no-delete-other-windows t)

I can see further down that the vertico-buffer--restore lambda attempts to restore these parameters to their original values. But it seems like that is never actually getting called.

Is there a bug around this (i.e., does delete-other-windows always cease working after keyboard-quitting a vertico command)?

Inspecting (symbol-function 'vertico-buffer--restore) inside a minibuffer-exit-hook of my own it seems like the function value is always nil. Looking at the lines that bind the restore function:

    (setq-local vertico-buffer--restore (make-symbol "vertico-buffer--restore"))
    (fset vertico-buffer--restore
          (lambda ()
           ...))
    ;; We cannot use a buffer-local minibuffer-exit-hook here.  The hook will
    ;; not be called when abnormally exiting the minibuffer from another buffer
    ;; via `keyboard-escape-quit'.
    (add-hook 'minibuffer-exit-hook vertico-buffer--restore)

Even if I inspect (symbol-function 'vertico-buffer--restore) immediately after the fset it is nil (though I may be overlooking some subtleties here around why make-symbol was used rather than just directly setting vertifo-buffer--restore to the quoted symbol).

[minad]

You can check by adding some messages to vertico--buffer-restore, and also comment out the code there for testing. The symbol is only used to isolate different restore hooks. Note that the read-minibuffer-restore-windows also affects restoration. You can try the four combinations of read-minibuffer-restore-windows=nil,t and vertico--buffer-restore=enabled,commented-out to see how the windows are restored or not.

Regarding your problem - what exactly are you trying to do? Can you create a minimal recipe which demonstrates the problem where the window state is not restored correctly?

[dgillis]

This appears more subtle than I initially thought: reproducing it seems related to using vertico-multiform-commands (or categories) with a :not buffer configuration while not initially in vertico-buffer-mode (comment in the lisp explains why I'm doing that).

Here's a minimal recipe to reproduce:

• Start emacs, loading the lisp below.
• Call split-window-right (exact command doesn't matter, just anything that will result in > 1 window in the frame).
• Do M-x then keyboard-quit without selecting anything.
• Attempt to delete the other window (delete-other-windows command): unexpectedly nothing happens.
• At this point the issue is reproduced: the other window cannot be deleted due to the window-parameters mentioned in my prior message not being removed.

I also notice that after performing the steps above, you end up being left with vertico-buffer-mode enabled following the aborted M-x command (even though it was disabled to begin with).

(require 'vertico)
(require 'vertico-multiform)

(setq vertico-multiform-commands
      '((execute-extended-command
      ;; This `:not buffer` line seems like a pre-req to reproducing the issue. Note that
      ;; I'm not enabling `vertico-buffer-mode`; so my expectation is it would have no
      ;; effect. The reason I have it in my config is I've been going back and forth between
      ;; using `vertico-buffer-mode` but my preference is in all cases to NOT use buffers
      ;; for this command.
      (:not buffer))))

(vertico-mode +1)
(vertico-multiform-mode +1)

[minad]

This is (or was) somewhat by design. The problem is that the :not modes in vertico-multiform-commands are disabled when entering the minibuffer, but enabled, when the minibuffer is left. This is quite confusing, so I added a check for the state of the mode in b3c3850.

[dgillis]

Thank you! 😃