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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 45177 in the body.
You can then email your comments to 45177 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: clemera <at> posteo.net
To: bug-gnu-emacs <at> gnu.org
Subject: 27.1; Access to invoking top level command in minibuffer
Date: Fri, 11 Dec 2020 15:20:34 +0100

Hello,

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'.

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.


    Clemens



In GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.30, 
cairo version 1.15.10)
 of 2020-08-20 built on clemera
Windowing system distributor 'The X.Org Foundation', version 11.0.11906000
System Description: Ubuntu 18.04.5 LTS

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Configured using:
 'configure --with-modules --with-json --with-cairo'

Configured features:
XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND GPM DBUS GSETTINGS GLIB NOTIFY
INOTIFY GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS JSON PDUMPER LCMS2
GMP

Important settings:
  value of $LC_MONETARY: de_DE.UTF-8
  value of $LC_NUMERIC: de_DE.UTF-8
  value of $LC_TIME: de_DE.UTF-8
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
format-spec rfc822 mml easymenu mml-sec password-cache epa derived epg
epg-config gnus-util rmail rmail-loaddefs text-property-search time-date
subr-x seq byte-opt gv bytecomp byte-compile cconv mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs
cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type
mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode
lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch
timer select scroll-bar mouse jit-lock font-lock syntax facemenu
font-core term/tty-colors frame minibuffer cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote threads dbusbind
inotify lcms2 dynamic-setting system-font-setting font-render-setting
cairo move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 44091 12180)
 (symbols 48 6003 1)
 (strings 32 15452 1784)
 (string-bytes 1 506298)
 (vectors 16 9257)
 (vector-slots 8 124488 12266)
 (floats 8 19 43)
 (intervals 56 183 0)
 (buffers 1000 11))

Message #8 received at 45177 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: clemera <at> posteo.net, 45177 <at> debbugs.gnu.org
Subject: RE: bug#45177: 27.1; Access to invoking top level command in
 minibuffer
Date: Fri, 11 Dec 2020 09:35:25 -0800 (PST)

> 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:

FWIW, `icicle-mode' puts this on `pre-command-hook':

(defun icicle-top-level-prep ()
  "Do top-level stuff.  Used in `pre-command-hook'."
  (unless (> (minibuffer-depth) 0)
    ;; ... <other stuff>
    (unless (memq this-command 
                  '(minibuffer-complete-and-exit
                    icicle-minibuffer-complete-and-exit
                    exit-minibuffer
                    icicle-exit-minibuffer))
      (setq icicle-last-top-level-command  this-command))
    ;; ... <other stuff>
    ))

(defvar icicle-last-top-level-command nil
  "Last top-level command used.")

Message #11 received at 45177 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: clemera <at> posteo.net
Cc: 45177 <at> debbugs.gnu.org
Subject: Re: bug#45177: 27.1; Access to invoking top level command in
 minibuffer
Date: Fri, 11 Dec 2020 21:41:58 +0100

clemera <at> posteo.net writes:

> 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'?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #14 received at 45177 <at> debbugs.gnu.org (full text, mbox):

From: Clemens <clemens.radermacher <at> posteo.de>
To: Drew Adams <drew.adams <at> oracle.com>, 45177 <at> debbugs.gnu.org
Subject: Re: bug#45177: 27.1; Access to invoking top level command in
 minibuffer
Date: Sat, 12 Dec 2020 14:28:10 +0100

> (defun icicle-top-level-prep ()
>    "Do top-level stuff.  Used in `pre-command-hook'."
>    (unless (> (minibuffer-depth) 0)
>      ;; ... <other stuff>
>      (unless (memq this-command
>                    '(minibuffer-complete-and-exit
>                      icicle-minibuffer-complete-and-exit
>                      exit-minibuffer
>                      icicle-exit-minibuffer))
>        (setq icicle-last-top-level-command  this-command))
>      ;; ... <other stuff>
>      ))
> 
> (defvar icicle-last-top-level-command nil
>    "Last top-level command used.")
> 


Thanks Drew! Looks like a nice workaround!

Message #17 received at 45177 <at> debbugs.gnu.org (full text, mbox):

From: clemera <at> posteo.net
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 45177 <at> debbugs.gnu.org
Subject: Re: bug#45177: 27.1; Access to invoking top level command in
 minibuffer
Date: Sat, 12 Dec 2020 14:31:07 +0100

> 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?

Yes, that would be ideal.

> 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'?

I don't know anything about the C side of Emacs so I can't be of any 
help here.

Message #20 received at 45177 <at> debbugs.gnu.org (full text, mbox):

From: clemera <at> posteo.net
To: Drew Adams <drew.adams <at> oracle.com>, clemera <at> posteo.net,
 45177 <at> debbugs.gnu.org
Subject: Re: bug#45177: 27.1; Access to invoking top level command in
 minibuffer
Date: Sat, 12 Dec 2020 14:39:47 +0100

> (defun icicle-top-level-prep ()
>    "Do top-level stuff.  Used in `pre-command-hook'."
>    (unless (> (minibuffer-depth) 0)
>      ;; ... <other stuff>
>      (unless (memq this-command
>                    '(minibuffer-complete-and-exit
>                      icicle-minibuffer-complete-and-exit
>                      exit-minibuffer
>                      icicle-exit-minibuffer))
>        (setq icicle-last-top-level-command  this-command))
>      ;; ... <other stuff>
>      ))
> 
> (defvar icicle-last-top-level-command nil
>    "Last top-level command used.")

Note that ideally I'm looking for something which allows me to
get the "innermost command that invoked a recursive
edit" as Lars described it.

Message #23 received at 45177 <at> debbugs.gnu.org (full text, mbox):

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: Re: 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.

Message #26 received at 45177 <at> debbugs.gnu.org (full text, mbox):

From: clemera <at> posteo.net
To: Juri Linkov <juri <at> linkov.net>, Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 45177 <at> debbugs.gnu.org
Subject: Re: bug#45177: 27.1; Access to invoking top level command in
 minibuffer
Date: Sat, 12 Dec 2020 22:25:49 +0100

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

But wouldn't this still have the problem that multiple minibuffer 
invocations in the same command would change real-this-command as in my 
initial example?

Message #29 received at 45177 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: clemera <at> posteo.net
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 45177 <at> debbugs.gnu.org
Subject: Re: bug#45177: 27.1; Access to invoking top level command in
 minibuffer
Date: Sun, 13 Dec 2020 10:47:41 +0200

>> Or set a (mini)buffer-local variable in minibuffer-setup-hook.
>
> But wouldn't this still have the problem that multiple minibuffer
> invocations in the same command would change real-this-command as in my
> initial example?

This is not a problem because multiple minibuffer invocations
create separate buffers with different names

  #<buffer  *Minibuf-1*>
  #<buffer  *Minibuf-2*>
  #<buffer  *Minibuf-3*>
 ...

Message #32 received at 45177 <at> debbugs.gnu.org (full text, mbox):

From: clemera <at> posteo.net
To: Juri Linkov <juri <at> linkov.net>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 45177 <at> debbugs.gnu.org
Subject: Re: bug#45177: 27.1; Access to invoking top level command in
 minibuffer
Date: Sun, 13 Dec 2020 12:40:18 +0100

>> But wouldn't this still have the problem that multiple minibuffer
>> invocations in the same command would change real-this-command as in my
>> initial example?
> 
> This is not a problem because multiple minibuffer invocations
> create separate buffers with different names
> 
>    #<buffer  *Minibuf-1*>
>    #<buffer  *Minibuf-2*>
>    #<buffer  *Minibuf-3*>
>   ...

I meant sequential invocation the local variables are gone when you exit 
a session (a nice feature that we also rely on in Selectrum):

```elisp
(defvar saved-command nil)

(defun save-command ()
  (message "Before: %s" saved-command)
  (setq-local saved-command real-this-command)
  (message "After: %s" saved-command))

(defun example-command ()
  (interactive)
  (read-string "Example1 : ")
  (read-string "Example2 : "))
```

Calling example-command above gives :

    Before: nil
    After: example-command

    Before: nil
    After: exit-minibuffer

Message #35 received at 45177 <at> debbugs.gnu.org (full text, mbox):

From: clemera <at> posteo.net
To: Juri Linkov <juri <at> linkov.net>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 45177 <at> debbugs.gnu.org
Subject: Re: bug#45177: 27.1; Access to invoking top level command in
 minibuffer
Date: Sun, 13 Dec 2020 12:45:28 +0100

I forgot to include the setup hook in my code example, here is the full 
version:

```elisp

(defvar saved-command nil)

(defun save-command ()
  (message "Before: %s" saved-command)
  (setq-local saved-command real-this-command)
  (message "After: %s" saved-command))

(defun example-command ()
  (interactive)
  (read-string "Example1 : ")
  (read-string "Example2 : "))

(add-hook 'minibuffer-setup-hook #'save-command)
```

Calling example-command above gives :

    Before: nil
    After: example-command

    Before: nil
    After: exit-minibuffer

Message #38 received at 45177 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: clemera <at> posteo.net
Cc: 45177 <at> debbugs.gnu.org
Subject: Re: bug#45177: 27.1; Access to invoking top level command in
 minibuffer
Date: Sun, 13 Dec 2020 13:29:06 +0100

clemera <at> posteo.net writes:

> I don't know anything about the C side of Emacs so I can't be of any
> help here.

I'm not quite sure where to bind the variable...  Does the following
work for you?

diff --git a/src/callint.c b/src/callint.c
index f80436f3d9..a01338dfe1 100644
--- a/src/callint.c
+++ b/src/callint.c
@@ -283,6 +283,8 @@ DEFUN ("call-interactively", Fcall_interactively, Scall_interactively, 1, 3, 0,
   Lisp_Object save_real_this_command = Vreal_this_command;
   Lisp_Object save_last_command = KVAR (current_kboard, Vlast_command);
 
+  specbind (Qrecursive_this_command, Vreal_this_command);
+
   if (NILP (keys))
     keys = this_command_keys, key_count = this_command_key_count;
   else
diff --git a/src/keyboard.c b/src/keyboard.c
index dbca5be91e..ce2b7f1ef4 100644
--- a/src/keyboard.c
+++ b/src/keyboard.c
@@ -11830,6 +11830,11 @@ syms_of_keyboard (void)
 	       doc: /* This is like `this-command', except that commands should never modify it.  */);
   Vreal_this_command = Qnil;
 
+  DEFSYM (Qrecursive_this_command, "recursive-this-command");
+  DEFVAR_LISP ("recursive-this-command", Vrecursive_this_command,
+	       doc: /* This is like `real-this-command', but bound recursively in `call-interactively.  */);
+  Vrecursive_this_command = Qnil;
+
   DEFVAR_LISP ("this-command-keys-shift-translated",
 	       Vthis_command_keys_shift_translated,
 	       doc: /* Non-nil if the key sequence activating this command was shift-translated.


-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #41 received at 45177 <at> debbugs.gnu.org (full text, mbox):

From: clemera <at> posteo.net
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 45177 <at> debbugs.gnu.org
Subject: Re: bug#45177: 27.1; Access to invoking top level command in
 minibuffer
Date: Sun, 13 Dec 2020 14:29:01 +0100

> I'm not quite sure where to bind the variable...  Does the following
> work for you?
> 
> diff --git a/src/callint.c b/src/callint.c
> index f80436f3d9..a01338dfe1 100644
> --- a/src/callint.c
> +++ b/src/callint.c
> @@ -283,6 +283,8 @@ DEFUN ("call-interactively", Fcall_interactively, Scall_interactively, 1, 3, 0,
>     Lisp_Object save_real_this_command = Vreal_this_command;
>     Lisp_Object save_last_command = KVAR (current_kboard, Vlast_command);
>   
> +  specbind (Qrecursive_this_command, Vreal_this_command);
> +
>     if (NILP (keys))
>       keys = this_command_keys, key_count = this_command_key_count;
>     else
> diff --git a/src/keyboard.c b/src/keyboard.c
> index dbca5be91e..ce2b7f1ef4 100644
> --- a/src/keyboard.c
> +++ b/src/keyboard.c
> @@ -11830,6 +11830,11 @@ syms_of_keyboard (void)
>   	       doc: /* This is like `this-command', except that commands should never modify it.  */);
>     Vreal_this_command = Qnil;
>   
> +  DEFSYM (Qrecursive_this_command, "recursive-this-command");
> +  DEFVAR_LISP ("recursive-this-command", Vrecursive_this_command,
> +	       doc: /* This is like `real-this-command', but bound recursively in `call-interactively.  */);
> +  Vrecursive_this_command = Qnil;
> +
>     DEFVAR_LISP ("this-command-keys-shift-translated",
>   	       Vthis_command_keys_shift_translated,
>   	       doc: /* Non-nil if the key sequence activating this command was shift-translated.
> 

Thank you! I recompiled Emacs with this and tested with various nested 
sequential and recursive calls and this correctly reports the top level 
command the current minibuffer session was entered from, which is 
exactly what we are looking for :)

Message #44 received at 45177 <at> debbugs.gnu.org (full text, mbox):

From: clemera <at> posteo.net
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 45177 <at> debbugs.gnu.org
Subject: Re: bug#45177: 27.1; Access to invoking top level command in
 minibuffer
Date: Sun, 13 Dec 2020 14:39:27 +0100

> the top level command the current minibuffer session was entered from

I rather meant the command that was current when entering the current 
minibuffer session.

Message #47 received at 45177 <at> debbugs.gnu.org (full text, mbox):

From: clemera <at> posteo.net
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 45177 <at> debbugs.gnu.org
Subject: Re: bug#45177: 27.1; Access to invoking top level command in
 minibuffer
Date: Sun, 13 Dec 2020 15:16:03 +0100

If you are going to include something like this would it make sense
to have an `real-recursive-this-command` and `recursive-this-command`?

Message #50 received at 45177 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: clemera <at> posteo.net
Cc: 45177 <at> debbugs.gnu.org
Subject: Re: bug#45177: 27.1; Access to invoking top level command in
 minibuffer
Date: Mon, 14 Dec 2020 16:45:06 +0100

clemera <at> posteo.net writes:

> Thank you! I recompiled Emacs with this and tested with various nested
> sequential and recursive calls and this correctly reports the top
> level command the current minibuffer session was entered from, which
> is exactly what we are looking for :)

Thanks for testing -- I've now pushed this to Emacs 28, but I renamed
the variable to `current-minibuffer-command'.  (And if somebody wants to
rename that, please go ahead.)

With that, I'm closing this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #57 received at 45177 <at> debbugs.gnu.org (full text, mbox):

From: Clemens <clemera <at> posteo.net>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 45177 <at> debbugs.gnu.org
Subject: Re: bug#45177: 27.1; Access to invoking top level command in
 minibuffer
Date: Mon, 14 Dec 2020 18:52:08 +0100

> Thanks for testing -- I've now pushed this to Emacs 28, but I renamed
> the variable to `current-minibuffer-command'.  (And if somebody wants to
> rename that, please go ahead.)


Thank you very much! I also think it was a good decision to make it 
point to `this-command` that makes more sense after all.

Message #60 received at 45177 <at> debbugs.gnu.org (full text, mbox):

From: Clemens <clemera <at> posteo.net>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 45177 <at> debbugs.gnu.org
Subject: Re: bug#45177: 27.1; Access to invoking top level command in
 minibuffer
Date: Mon, 14 Dec 2020 19:01:06 +0100

Oh I just noticed it still points to real-this-command right? I was
mislead by the docs ;) My thought why `this-command` might have been
a good idea was that people might want to call commands from Elisp like this

(let ((this-command 'my-cmd))
    (call-interactively 'my-cmd))

and then expect the configuration of the minibuffer applied by Selectrum 
to apply. To make this work with real-this-command they would need to 
bind that but it is discouraged I think? This is mostly a consideration 
about what might happen in user code later.

Message #63 received at 45177 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Clemens <clemera <at> posteo.net>
Cc: 45177 <at> debbugs.gnu.org
Subject: Re: bug#45177: 27.1; Access to invoking top level command in
 minibuffer
Date: Tue, 15 Dec 2020 07:18:39 +0100

Clemens <clemera <at> posteo.net> writes:

> Oh I just noticed it still points to real-this-command right? I was
> mislead by the docs ;) My thought why `this-command` might have been
> a good idea was that people might want to call commands from Elisp like this
>
> (let ((this-command 'my-cmd))
>     (call-interactively 'my-cmd))
>
> and then expect the configuration of the minibuffer applied by
> Selectrum to apply. To make this work with real-this-command they
> would need to bind that but it is discouraged I think? This is mostly
> a consideration about what might happen in user code later.

Good catch; I meant to change it to this-command, but I forgot to change
it in the actual binding.  Fixed now.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #66 received at 45177 <at> debbugs.gnu.org (full text, mbox):

From: Clemens <clemera <at> posteo.net>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 45177 <at> debbugs.gnu.org
Subject: Re: bug#45177: 27.1; Access to invoking top level command in
 minibuffer
Date: Tue, 15 Dec 2020 12:58:28 +0100

> Good catch; I meant to change it to this-command, but I forgot to change
> it in the actual binding.  Fixed now.

Thank you!

Message #69 received at 45177 <at> debbugs.gnu.org (full text, mbox):

From: Clemens <clemera <at> posteo.net>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 45177 <at> debbugs.gnu.org
Subject: Re: bug#45177: 27.1; Access to invoking top level command in
 minibuffer
Date: Tue, 12 Jan 2021 09:46:40 +0100

After some experiments, this isn't sufficient for our purposes. What we 
would really need is identifying the call which invokes the minibuffer 
session. Having access to the surrounding function call would help, in 
combination with the prompt text and in some cases completion table data 
this should work. I guess we need to use advice or would it be possible 
to expose the surrounding function call of the current minibuffer session?

I think having the new variable is still an improvement as one just 
hadn't access to this sate before and it can be used for other purposes 
as minibuffer session configuration, too.

Message #76 received at 45177 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: clemera <at> posteo.net
Cc: 45177 <at> debbugs.gnu.org
Subject: Re: 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

Message #79 received at 45177 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 45177 <at> debbugs.gnu.org, clemera <at> posteo.net
Subject: Re: bug#45177: 27.1; Access to invoking top level command in
 minibuffer
Date: Mon, 02 Aug 2021 00:04:05 -0400

[ Resending because of that damn archiving misfeature.  ]

> Thanks for testing -- I've now pushed this to Emacs 28, but I renamed
> the variable to `current-minibuffer-command'.  (And if somebody wants to
> rename that, please go ahead.)
> With that, I'm closing this bug report.

Using such let-binding is exactly what we're trying to move away from;
we should bind it buffer-locally in the minibuffer instead (as we've
seen with `minibuffer-local-map`).


        Stefan

Message #82 received at 45177 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 45177 <at> debbugs.gnu.org, clemera <at> posteo.net
Subject: Re: bug#45177: 27.1; Access to invoking top level command in
 minibuffer
Date: Wed, 04 Aug 2021 07:49:32 +0200

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> Using such let-binding is exactly what we're trying to move away from;
> we should bind it buffer-locally in the minibuffer instead (as we've
> seen with `minibuffer-local-map`).

Sure -- I guess the results will be pretty much the same when using a
recursive minibuffer?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #85 received at 45177 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 45177 <at> debbugs.gnu.org, clemera <at> posteo.net
Subject: Re: bug#45177: 27.1; Access to invoking top level command in
 minibuffer
Date: Wed, 04 Aug 2021 07:51:17 +0200

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> 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.

It's not ideal to look at the name, of course, but I think the user
should have a mechanism to do so anyway -- it's an easy and practical
way for users to tweak stuff.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

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