GNU bug report logs - #45177
27.1; Access to invoking top level command in minibuffer

Previous Next

Package: emacs;

Reported by: clemera <at> posteo.net

Date: Fri, 11 Dec 2020 14:21:02 UTC

Severity: normal

Tags: fixed

Found in version 27.1

Fixed in version 28.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: clemera <at> posteo.net
Cc: 45177 <at> debbugs.gnu.org
Subject: bug#45177: 27.1; Access to invoking top level command in minibuffer
Date: Mon, 02 Aug 2021 00:03:32 -0400
[ Resending because of that damn archiving misfeature.  ]

clemera <at> 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





This bug report was last modified 3 years and 330 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.