launching a completing read from command line initially does not show options

[kim366]

When running

emacs --eval '(completing-read "Choose" \'("Option A" "Option B"))'

from a command line with vertico configured, the minibuffer correctly shows up and asks for options.

The initial options are, however, not shown. This can temporarily be "fixed" by typing something in the prompt and then deleting the query.

So it seems that some initialization is skipped when directly launching a completing read.

I have tried multiple completion styles and also a consulting read, so I believe the issue is with vertico.

My vertico configuration is simply

(straight-use-package 'vertico)
(vertico-mode 1)

PS: very impressed by the bug squashing and 0 open issues :) sorry to open one now

[minad]

PS: very impressed by the bug squashing and 0 open issues :) sorry to open one now

Can you help me convince that this is actually a bug? ;) Similar problems where Vertico hasn't shown up have been occured before, but not on more recent Emacs versions. The problem is usually that an input event is lost such that Vertico isn't updated:

Oddly this works on TTY:

emacs -nw -Q --eval '(progn (package-initialize) (vertico-mode) (completing-read "Prompt: " (list "foo" "bar")))'

But I can confirm that it does not work on GUI:

emacs -Q --eval '(progn (package-initialize) (vertico-mode) (completing-read "Prompt: " (list "foo" "bar")))'

But why should it? There is no input event, so Vertico not showing up seems expected. I am not sure if this counts as a bug given that calling completing read from the command line is a special use case. While I make up my mind about this you can work around it by calling vertico--exhibit from a timer:

emacs -Q --eval '(progn (package-initialize) (vertico-mode) (run-at-time 0.2 nil (intern "vertico--exhibit")) (completing-read "Prompt: " (list "foo" "bar")))'

[minad]

Btw I wonder about your use case. Starting Emacs just to display Vertico is likely super slow for any quick interactivity (maybe 0.1s at best). On the other hand you might actually be using emacsclient and this problem occurs there too?

[kim366]

Hi, thanks for the quick reply! I am indeed going to use emacsclient -c and had the issue initially phrased with that but then chose pure emacs, as this might reduce the complexity of the issue.

In the long run, I will have a hidden emacs window open at all times and temporarily show it through my WM, eliminating startup costs and circumventing this issue.

Anyways, I‘m happy with your proposed workaround and I‘m fine with closing this issue, when this is declared intended behavior.

[minad]

Anyways, I‘m happy with your proposed workaround and I‘m fine with closing this issue, when this is declared intended behavior.

It is not intended behavior, but there is some event handling inconsistency in how Emacs handles completing-read in --eval as I've shown above with -nw vs GUI.

I've also tried to call vertico--exhibit directly after the Vertico setup, which does not work. This means that minibuffer resizing is broken for some reason after Emacs startup and only works if we delay it a bit with a timer.

emacs -Q --eval "(progn (package-initialize) (vertico-mode) (advice-add #'vertico--setup :after #'vertico--exhibit) (completing-read \"Prompt: \" '(foo bar)))"

[kim366]

I see, that make sense. Then intended in the sense of noted and outside the scope of this package.

[minad]

Well, I think it would be better to improve Emacs such that it behaves reliably and consistently (see above nw vs GUI). At first one has to understand why this happens.