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: Juri Linkov <juri <at> linkov.net>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 45177 <at> debbugs.gnu.org, clemera <at> posteo.net
Subject: bug#45177: 27.1; Access to invoking top level command in minibuffer
Date: Sat, 12 Dec 2020 22:14:48 +0200
>> 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'.
>
> Hm...  I'm not quite sure "the top level command" is a well-defined
> concept?  You can enter a number of nested recursive edits, and I think
> what you probably want is the innermost command that invoked a recursive
> edit?
>
> So perhaps it would make sense for Frecursive_edit (or some other handy
> function when entering the minibuffer) to let-bind a new variable (say,
> `this-recursive-command'?) to the value of `real-this-command'?

Or set a (mini)buffer-local variable in minibuffer-setup-hook.




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.