bug#45177: 27.1; Access to invoking top level command in minibuffer

[Stefan Monnier]

[ Resending because of that damn archiving misfeature.  ]

clemera@posteo.net [2020-12-11 15:20:34] wrote:
> For command based settings it would be nice to be able to have
> access to the top level command from which the current minibuffer
> session was invoked from. This should also work with multiple minibuffer
> invokations during a command. Using `minibuffer-setup-hook' to save
> `real-this-command' does not work, for example with:
>
> ```elisp
> (defun example-command ()
>   (interactive)
>   (read-string "Example: ")
>   (message "%s" real-this-command))
> ```
>
> `real-this-command' will be `exit-minibuffer' after the `read-string' so any
> minibuffer invokation within that command afterwards will no longer know
> about `example-command'.

If you invoke `example-command` from an alias, you won't get "the right"
answer either anyway.

> The described issue is problem for completion frameworks. The popular
> Ivy(https://github.com/abo-abo/swiper/) package from GNU ELPA does use the
> `:caller` argument passed to `ivy-read` to circumvent this. With
> Selectrum(https://github.com/raxod502/selectrum/) we are trying to find
> a built-in way to handle this.

I think this is an XY problem.

Changing the behavior based on the caller's name is a very bad idea.
It's a bit like `called-interactively-p`, except it's worse because
you're looking for even more ill-defined data than just a boolean.

The standard UI has introduced the `category` metadata for that kind
of problems.  I don't claim it's a perfect solution, but whichever
"right" solution we come up with it should not be based on the name of
the caller but instead it should be based on data provided by
the caller.


        Stefan