call-interactively does not use consult-customize

[ErnestKz]

For example, when customizing consult-find:

(consult-customize
 consult-find
 :prompt "hello")

Invoking it via extended command yields a prompt of "hello".

Whereas (call-interactively 'consult-find) uses the defaults, ignoring the customized version.

[ErnestKz]

Well, I now realise it's not a bug, but a little bit of a tragedy :(

this-command is not set by call-interactively, which consult--customize-get requires to function.

(defun consult--customize-get (&optional cmd)
  "Get configuration from `consult--customize-alist' for CMD."
  (mapcar (lambda (x) (eval x 'lexical))
          (alist-get (or cmd this-command) consult--customize-alist)))

[ErnestKz]

If you may be graceful enough to receive my contrary perspective against consults and verticos usage of this-command, perhaps previous-command and this-command is intended and understood to be used in-conjunction such that the elisp can know if the user is chaining inputted commands via key-presses.

Rather how we use it here for consult and vertico as a variable to store things for a command, because there are other mechanisms which can offer that, and also work in more justified use cases. (i.e defining a new variable with its own name just for use to look-up, in the calling command)

[minad]

Yes, using this-command for looking up configuration is brittle and may break in special cases, where commands are chained. But we don't have better mechanisms unfortunately. For vertico-multiform we can also use the completion category, but of course this works only if the command defines a category in the first place.

[minad]

I'm happy with my workaround, but are you saying project-switch-commands should use a modified call-interactively such that it sets the this-command? I think it make sense, since project-switch-commands for a good few cases calls commands that are intended to be used actually interactively.

Not a modified version of call-interactively. It could simply set this-command before.

[ErnestKz]

It seems you're perceiving a slightly jumbled up meaning of what I'm saying. I'm saying this-command is mostly intended to be used with last-command in order to detect a chain of commands key'd in by the user. Like the first example on this page

we don't have better mechanisms unfortunately

Surely there are other mechanisms, maybe not as syntactically elegant, and requiring some extra code.

Not a modified version of call-interactively. It could simply set this-command before.

Mmm right, and it would have to set previous-command to the this-command before that (perhaps? i havent though it too much through)

[minad]

Maybe I've misunderstood you. However this-command and last-command can be used for many different things, e.g., redirecting commands in a pre-command-hook or detecting the current command as we do here. In any case, the mechanism will stay as is, as long as no better alternative comes along. If you have a better idea, please let me know. But to be clear, I am likely not going to accept it, if it leads to much more code, or has other downsides. Also note that the current mechanism has advantages, for example if you define an alias of a command, it can get its own configuration. This is intentional and wouldn't be possible if we hard-code the command name, for example passing the current command symbol to consult--read (either implicitly or via some macro or stack trace trickery).