From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#45474: Icomplete exhibiting in recursive minibuffer when it =?UTF-8?Q?shouldn=E2=80=99t?= Date: Sun, 18 Apr 2021 10:44:57 -0400 Message-ID: References: <3ed97a9c53e0a5d4fef8@heytings.org> <87fszrz21d.fsf@mail.linkov.net> <3ed97a9c530093aca93d@heytings.org> <7dee3f4235d331cab291@heytings.org> <87r1jatd34.fsf@mail.linkov.net> <7dee3f423551aaf318cb@heytings.org> <87im4kzlfm.fsf@mail.linkov.net> <1869622e16546eafd9df@heytings.org> <1869622e16dc36c3f2fd@heytings.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15602"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Dario Gjorgjevski , 45474@debbugs.gnu.org, Juri Linkov To: Gregory Heytings Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Apr 18 16:46:41 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lY8h6-0003wj-En for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 18 Apr 2021 16:46:40 +0200 Original-Received: from localhost ([::1]:57700 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lY8h5-0006Vo-1G for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 18 Apr 2021 10:46:39 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56440) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lY8gV-0006VV-2Q for bug-gnu-emacs@gnu.org; Sun, 18 Apr 2021 10:46:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:35850) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lY8gU-0002JN-DH for bug-gnu-emacs@gnu.org; Sun, 18 Apr 2021 10:46:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lY8gU-0002Y4-A3 for bug-gnu-emacs@gnu.org; Sun, 18 Apr 2021 10:46:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 18 Apr 2021 14:46:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 45474 X-GNU-PR-Package: emacs Original-Received: via spool by 45474-submit@debbugs.gnu.org id=B45474.16187571099728 (code B ref 45474); Sun, 18 Apr 2021 14:46:02 +0000 Original-Received: (at 45474) by debbugs.gnu.org; 18 Apr 2021 14:45:09 +0000 Original-Received: from localhost ([127.0.0.1]:47396 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lY8fb-0002Wp-SK for submit@debbugs.gnu.org; Sun, 18 Apr 2021 10:45:08 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:12011) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lY8fa-0002W2-2m for 45474@debbugs.gnu.org; Sun, 18 Apr 2021 10:45:06 -0400 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 750B4440F7A; Sun, 18 Apr 2021 10:45:00 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id A1FBA440F72; Sun, 18 Apr 2021 10:44:58 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1618757098; bh=NDhd2jIRIdMqcL06pkJYewNAKCGhseO+b8vE/BQbm/M=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=AGo6iLaffDSMk4M9XQfOEh7dJ9EfQyaW9q9tzB1S19zG0kfvsSshmE8B8R7pJsnU9 2TPzHhvq/H/o1SMLCE5El/YEBMOyWzNV/mvtmBOJxztIMRCTp2uktqhIu2x4FXFtik cCOjM3lATE+NP7y28n7yl5E+xFu1Zad9ctwAFDDtUEut3jneI8RR3hLQHs/w2RyXkb s9rusy6d6InH4T7kUXHcH5UtG1vtW7j4HzRAtYGVJDjk1EzyHGm4MQy62TnWd8iiI+ ZkMYGVDAgy/nTruhGJNHgiZJYskPg4fwfMC2m7VLLUJ5Xaf+ku9eljPFasgBKZrwAo RVusNpMr2JRNw== Original-Received: from alfajor (104-222-126-84.cpe.teksavvy.com [104.222.126.84]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 6AD941200C3; Sun, 18 Apr 2021 10:44:58 -0400 (EDT) In-Reply-To: <1869622e16dc36c3f2fd@heytings.org> (Gregory Heytings's message of "Sat, 17 Apr 2021 22:16:16 +0000") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:204339 Archived-At: >>> 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'.