bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#45474: Icomplete exhibiting in recursive minibuffer when it shouldn’


From: Stefan Monnier
Subject: bug#45474: Icomplete exhibiting in recursive minibuffer when it shouldn’t
Date: Sun, 18 Apr 2021 10:44:57 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

>>> What's wrong with my approach, which disables the completion backend
>>> on demand?
>> [ I'm not sure which is "your approach", sorry.  ]
> See the attached patch.  I's a draft, as I said read-from-minibuffer-simple
> could probably renamed to something more elegant, and (at least some of) the
> other calls to read-from-minibuffer could be replaced by the macro.

Ah, I see.  But that's based on "blacklisting" those places that don't
want to use minibuffer-completion-table, so it requires changes in many
places (including outside of Emacs's codebase).

> These are yet other possible approaches indeed, but it seems to me at first
> sight that they are more complex than the solution I suggest.

The patch below shows one way to do what I suggest.

Just like your approach, I think this is only a temporary fix until we
can solve the problem for real by making `minibuffer-completion-table`
buffer-local (which is also indispensable if we want to make completion
work with Alan's new support for having several active minibuffers
visible at the same time).


        Stefan


diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index c900b0d7ce6..e148c73889d 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -3843,6 +3843,7 @@ completing-read-default
                     ;; in minibuffer-local-filename-completion-map can
                     ;; override bindings in base-keymap.
                     base-keymap)))
+         (minibuffer--completion-keymap keymap)
          (result (read-from-minibuffer prompt initial-input keymap
                                        nil hist def inherit-input-method)))
     (when (and (equal result "") def)
diff --git a/src/minibuf.c b/src/minibuf.c
index a3c1b99bf32..872928ad578 100644
--- a/src/minibuf.c
+++ b/src/minibuf.c
@@ -563,6 +563,9 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, 
Lisp_Object prompt,
   specbind (Qminibuffer_default, defalt);
   specbind (Qinhibit_read_only, Qnil);
 
+  if (!EQ (Vminibuffer__completion_keymap, map))
+    specbind (Qminibuffer_completion_table, Qnil);
+
   /* If Vminibuffer_completing_file_name is `lambda' on entry, it was t
      in previous recursive minibuffer, but was not set explicitly
      to t for this invocation, so set it to nil in this minibuffer.
@@ -1348,12 +1351,6 @@ DEFUN ("read-string", Fread_string, Sread_string, 1, 5, 
0,
   Lisp_Object val;
   ptrdiff_t count = SPECPDL_INDEX ();
 
-  /* Just in case we're in a recursive minibuffer, make it clear that the
-     previous minibuffer's completion table does not apply to the new
-     minibuffer.
-     FIXME: `minibuffer-completion-table' should be buffer-local instead.  */
-  specbind (Qminibuffer_completion_table, Qnil);
-
   val = Fread_from_minibuffer (prompt, initial_input, Qnil,
                               Qnil, history, default_value,
                               inherit_input_method);
@@ -2404,6 +2401,12 @@ syms_of_minibuf (void)
 variable is non-nil. */);
   enable_recursive_minibuffers = 0;
 
+  DEFVAR_LISP ("minibuffer--completion-keymap", Vminibuffer__completion_keymap,
+               doc: /* Keymap used together with `minibuffer-completion-table'.
+`read-from-minibuffer' compares it with its `keymap' to determine if
+the completion table was intended for it or not.  */);
+  Vminibuffer__completion_keymap = Qnil;
+
   DEFVAR_LISP ("minibuffer-completion-table", Vminibuffer_completion_table,
               doc: /* Alist or obarray used for completion in the minibuffer.
 This becomes the ALIST argument to `try-completion' and `all-completions'.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]