Tried it in EXWM, noticed a few issues

[David Wilson]

Hey @minad! Here's a quick video capture of me trying mini-popup in EXWM. There are three things I noticed:

• I use C-j and C-k as vertico-next/vertico-previous bindings in minibuffers but for some reason C-k doesn't work in the popup window (I've noticed this with Corfu too, just hadn't reported it yet)
• When I open a minibuffer popup and then switch EXWM workspaces a few times, the minibuffer will switch back to the original location in the frames on other workspaces. Ideally the minibuffer would stay connected to the original workspace it was opened on and not appear on other workspaces
• Sometimes when I run a command like describe-variable, no completion results will be displayed with an empty input. Wasn't able to capture that one on this recording, though.

Thanks for giving this a shot!

mini-popup-exwm.mp4

[Daniel Mendler]

1. Not sure what causes this. What I would try - take a look at the corfu/vertico-map and remove all the remappings or start from an empty keymap. It can be that the issue is a remapping which is interfering here. It could also be some interaction with evil-mode?
2. The current implementation uses only one child frame which is reused all the time. We could certainly recreate the child frame every time, but this is a bit slower in the simple use cases.
3. This may be related to some issues where Vertico is not immediately updating. I think a (run-at-time 0 nil #'vertico--exhibit) at the end of vertico--setup may be needed.

Note that mini-popup will not work well with EXWM in general since the X11 windows will be shown on top of the child frame windows. I think mini-popup is more a replacement for ivy-posframe and for this purpose it works well. For all the more complicated scenarios, mini-frame is the better bet. mini-frame can also show the Completions buffer in a child frame, so it does a lot more.

[Daniel Mendler]

Btw, @daviwil does it make sense to use a dedicated minibuffer frame in EXWM? If you add the following to the configuration, every frame is started without a minibuffer. And then the minibuffer pops up in a dedicated frame.

(mapc (lambda (p)
          (add-to-list 'initial-frame-alist p)
          (add-to-list 'default-frame-alist p))
        '((minibuffer . nil)
          (menu-bar-lines . 0)
          (tool-bar-lines . 0)
          (vertical-scroll-bars . nil)
          (horizontal-scroll-bars . nil)))

Is this too inconvenient? Since under the hood this is essentially what you get with mini-frame too on EXWM. I would like to understand a bit better what the best configuration for Vertico is for each scenario (such infos would be a good fit for the wiki).

1. Plain old minibuffer - unfortunately bumps the windows, but works well in all scenarios
2. No EXWM, floating window - use mini-popup (or mini-frame without special standalone configuration)
3. EXWM, floating window - use mini-frame with special standalone configuration
4. EXWM, floating window - use dedicated mini-frame (see above) and teach EXWM that it floats on top of everything

[Jeroen Wijenbergh]

vertico-next and vertico-previous not working is definitely an evil-mode issue, I have the same problem. As a quick hack I just use the following:

(advice-add #'mini-popup--setup :after #'turn-off-evil-mode)

[Colin McLear]

Just FYI -- I had the same issues with vertico-next and vertico-previous not working properly with evil but declaring the states explicitly in which the commands are bound seems to work and resolve the issue. I have the following in my use-package declaration (note that this uses general.el):

  :general
  (:states '(normal insert emacs) :keymaps 'vertico-map
   "C-j"     #'vertico-next
   "C-k"    #'vertico-previous)