Cannot use vertico-mode for M-x in emacs -q

[oantolin]

Vertico works perfectly in my personal configuration, but if I try emacs -Q, then M-x package-initialize, M-x vertico-mode, and then M-x again, Vertico displays the number of candidates: 1/3860 M-x and an error message:

Error in post-command-hook (vertico--exhibit): (wrong-type-argument stringp nil)

The error occurs with M-x, but not with find-file, for example.

[minad]

Your Emacs 28 is too old :)

[oantolin]

Oh? It does work in my personal configuration on this same version of Emacs.

[oantolin]

I just ran M-x vertico-mode to turn it off, then M-x toggle-debug-on-error, then M-x vertico-mode again. And now M-x works. It seems like some sort of loading order bug?

EDIT: Did this again in another instance of emacs -Q where I loaded ledger-mode and that didn't fix M-x under Vertico. I have no clue what is going on.

[minad]

Yes, because you are using Marginalia there. The problem is that M-x defines its own annotators and I proposed to change the affixation-function definition in upstream (see emacs-mirror/emacs@d8e037e).

Since Emacs master/native-comp had been broken recently and Vertico is not a widespread package, I didn't bother about fixing this issue to support broken Emacs master versions. How do you install Emacs master? I am also using Emacs master now for testing and I do a recompile every few days.

[minad]

The loading order bug you are observing though is weird. Are you sure that it worked like this? In any case you need an Emacs newer than emacs-mirror/emacs@d8e037e or Emacs 27.1 or 27.2.

You probably also remember the completion--require-match issue, which somehow shows that Emacs master is a moving target. So I am not aiming to make my packages compatible with broken Emacs master versions. The only promise I make is 27.1, 27.2 and a reasonably current master. And from time to time breakage happens even on a new master commit, e.g., two days ago M-x was broken due to some invalid commit.

[oantolin]

The problem is that M-x defines its own annotators and I proposed to change the affixation-function definition in upstream (see emacs-mirror/emacs@d8e037e).

Oh, I see. (By the way, the problem isn't that you proposed the change, but rather that it was accepted. 😛) I guess we should just close this then.

How do you install Emacs master?

I use this Debian repo: http://emacs.ganneff.de/ (On my Chromebook compiling is slow and awkward and I have very little disk space so I'd rather not install all the dev packages and the full GCC tool chain.)

The loading order bug you are observing though is weird. Are you sure that it worked like this?

No, I'm not sure. I tried again and couldn't get M-x to work. I don't know what I did when it did work, but I think I did not load Marginalia.

[oantolin]

So I am not aiming to make my packages compatible with broken Emacs master versions.

I wouldn't call the versions I've seen problems with "broken". But if you change "broken" to "all", I fully agree with the sentiment. 😉

[minad]

Oh, I see. (By the way, the problem isn't that you proposed the change, but rather that it was accepted. stuck_out_tongue) I guess we should just close this then.

😆

(But actually the change is quite reasonable. The old calling convention was mostly accidental and defined through how the default UI calls the affixation function.)

I use this Debian repo: http://emacs.ganneff.de/ (On my Chromebook compiling is slow and awkward and I have very little disk space so I'd rather not install all the dev packages and the full GCC tool chain.)

Makes sense. I hope not too many people are affected by this (using distribution archives like you). I thought this ganneff page was outdated, but now it seems to have gotten some updates recently. I hope it gets another recent update soon. I have to compile Emacs master myself in order to test a few patches.

No, I'm not sure. I tried again and couldn't get M-x to work. I don't know what I did when it did work, but I think I did not load Marginalia.

I have no idea then why it worked.

[minad]

I wouldn't call the versions I've seen problems with "broken". But if you change "broken" to "all", I fully agree with the sentiment.

Of course. But some are really broken. See for example #13. This was actually an interesting one, since there was a bug in native compilation which got only triggered by Consult and Vertico. It seems that I am the only person who writes propertized string literals which got then hash-consed together ;)

[oantolin]

I did see the propertized literals native compilation bug! That was an interesting one. And yes, propertized literals do not seem popular. I don't use them just because I feel I can write code to propertize faster than I could look up the correct literal syntax...

[minad]

And yes, propertized literals do not seem popular.

I don't really know why I used them. Maybe propertize is even executed at compile time by the bytecode compiler since it is marked as side-effect-free? So there is really no reason to use them. But I am glad I did since it uncovered this bug. So we should probably try to use all odd features to get bugs sorted out.

Another one I've observed in 27.1 26 - setf does not return the set value which is in conflict with its documentation. But this got fixed a while ago (in 27.1), but has been there for years.