GNU bug report logs - #45474
Icomplete exhibiting in recursive minibuffer when it shouldn’t

Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.

Package: emacs; Reported by: Dario Gjorgjevski <dario.gjorgjevski@HIDDEN>; dated Sun, 27 Dec 2020 17:45:02 UTC; Maintainer for emacs is bug-gnu-emacs@HIDDEN.

Message received at 45474 <at> debbugs.gnu.org:


Received: (at 45474) by debbugs.gnu.org; 3 May 2021 08:40:43 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon May 03 04:40:43 2021
Received: from localhost ([127.0.0.1]:46169 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1ldU8B-0005O3-7z
	for submit <at> debbugs.gnu.org; Mon, 03 May 2021 04:40:43 -0400
Received: from heytings.org ([95.142.160.155]:35258)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <gregory@HIDDEN>) id 1ldU89-0005Nx-Fy
 for 45474 <at> debbugs.gnu.org; Mon, 03 May 2021 04:40:42 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org;
 s=20210101; t=1620031239;
 bh=aAVfFBWmDti80BekypsONcXn3FIC9W1m+pDvCbLL40Q=;
 h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From;
 b=Oe49dUAxpZYhU33isatpS0cjSiT5GwRDQKzULrSqUlVUEhBrp7nMBy92L4yomA07v
 SzeFjlXruTHQoL23IwvntvFXDZU4WLxNHkx1zVCxZg+sgvxs5UlUuWS90x9chcRn2t
 3OX1hfPzyUK88CmFkdlI4ETJ1FHuKcsFMDfPoBJp5hcxUCWvCVN+YPr8XF/6/fk5xb
 u/jGtNxsOvbf1zoxDevjSWGjGD5gKJIsX++Y4COP/Ri63NiLGbW9xiBN9y6sUbenv1
 G7oS4QYrq6yjUkcVekMmT+HXhrC4vnWFl6nkJFDThClgzoN+AArBiry2vpgql8nwne
 9RBScWFp/nK1A==
Date: Mon, 03 May 2021 08:40:38 +0000
From: Gregory Heytings <gregory@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
Subject: =?UTF-8?Q?Re=3A_bug#45474=3A_Icomplete_exhibiting_in_recursive?=
 =?UTF-8?Q?_minibuffer_when_it_shouldn=E2=80=99t?=
In-Reply-To: <jwvr1iq1c9j.fsf-monnier+emacs@HIDDEN>
Message-ID: <a4dfe72ae2f1a3c8f35c@HIDDEN>
References: <fv2zojtus7b0tz.fsf@HIDDEN>
 <jwvczuqrm7s.fsf-monnier+emacs@HIDDEN> <87lf9cepqw.fsf@HIDDEN>
 <jwvsg3iig5h.fsf-monnier+emacs@HIDDEN>
 <jwvbla6if85.fsf-monnier+emacs@HIDDEN> <a87041afcb5f214d96a5@HIDDEN>
 <a87041afcb505462c0d5@HIDDEN>
 <jwv35vigog8.fsf-monnier+emacs@HIDDEN> <a87041afcb4761711a9a@HIDDEN>
 <jwv1rb1dhyu.fsf-monnier+emacs@HIDDEN> <f2b9666c4a7c09220e53@HIDDEN>
 <jwvmttp9mb4.fsf-monnier+emacs@HIDDEN> <f2b9666c4ad3eb906830@HIDDEN>
 <jwvwnst6n9z.fsf-monnier+emacs@HIDDEN>
 <f2b9666c4af5495f32cb@HIDDEN> <jwvh7jx6jfn.fsf-monnier+emacs@HIDDEN>
 <f2b9666c4af154b8671e@HIDDEN> <jwvh7jw6a6m.fsf-monnier+emacs@HIDDEN>
 <f2b9666c4a0baa3a67e2@HIDDEN> <jwvbla44qoy.fsf-monnier+emacs@HIDDEN>
 <7ee648e8400708d266ed@HIDDEN>
 <jwvr1iq1c9j.fsf-monnier+emacs@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset=us-ascii
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 45474
Cc: Dario Gjorgjevski <dario.gjorgjevski@HIDDEN>, 45474 <at> debbugs.gnu.org,
 Juri Linkov <juri@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)


>
> OK, seeing how noone reported problems with my patch, I pushed it to 
> `master`.  In case someone later reports a problem, we may "revert" to 
> your approach if its slightly better compatibility proves useful.
>

Okay, I guess the best thing to do now is to just let it go.  The main 
point of my approach was not a better compatibility, but to fix that 
problem in a more general way that would have cleaned up the situation in 
a longer term.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45474; Package emacs. Full text available.

Message received at 45474 <at> debbugs.gnu.org:


Received: (at 45474) by debbugs.gnu.org; 1 May 2021 19:34:54 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat May 01 15:34:54 2021
Received: from localhost ([127.0.0.1]:38014 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lcvOA-0004qS-5C
	for submit <at> debbugs.gnu.org; Sat, 01 May 2021 15:34:54 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:6808)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1lcvO8-0004qM-TO
 for 45474 <at> debbugs.gnu.org; Sat, 01 May 2021 15:34:53 -0400
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
 by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 39D9C440794;
 Sat,  1 May 2021 15:34:47 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id B9265440717;
 Sat,  1 May 2021 15:34:45 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1619897685;
 bh=JQchzvIMSyDOj0Ah3GinrijJGXP8Bc8apapyu+R4/Hg=;
 h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
 b=Jn241qJFAmmxMftSCvNhrTwOtQDs0Nx22Ei7DvzoyM648kYqPyRpFu5P0sglyk4P7
 0spRjHeHrZjyPATqc4OyyL2j6vOI49J1igjVC5IRTVMqevIn/42LN7zU0fnbeWJXHp
 jJ9Rzpojkl643sYqhX6/wSWmgncQwcjBEJ2Q4L3w9te5rQTavwgxx/eK+wR0oI9HpM
 QtzLQrZ/oR1m+kdkbh5YhzW1YGMGnG3nSeVz5Q+mbzDzZAVgVRnulBRtOEbyFAOcqg
 nr+wJUa2Q/NcZMIDDaQZxte81/pTVSzSP+WAo77t1PIkv9UPvH+b57t31G2eeK+Rp3
 EZusQioOMzpHg==
Received: from alfajor (unknown [108.161.125.61])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 6DBB3120262;
 Sat,  1 May 2021 15:34:45 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Gregory Heytings <gregory@HIDDEN>
Subject: Re: bug#45474: Icomplete exhibiting in recursive minibuffer when it
 =?utf-8?Q?shouldn=E2=80=99t?=
Message-ID: <jwvr1iq1c9j.fsf-monnier+emacs@HIDDEN>
References: <fv2zojtus7b0tz.fsf@HIDDEN>
 <jwvczuqrm7s.fsf-monnier+emacs@HIDDEN>
 <87lf9cepqw.fsf@HIDDEN>
 <jwvsg3iig5h.fsf-monnier+emacs@HIDDEN>
 <jwvbla6if85.fsf-monnier+emacs@HIDDEN>
 <a87041afcb5f214d96a5@HIDDEN>
 <a87041afcb505462c0d5@HIDDEN>
 <jwv35vigog8.fsf-monnier+emacs@HIDDEN>
 <a87041afcb4761711a9a@HIDDEN>
 <jwv1rb1dhyu.fsf-monnier+emacs@HIDDEN>
 <f2b9666c4a7c09220e53@HIDDEN>
 <jwvmttp9mb4.fsf-monnier+emacs@HIDDEN>
 <f2b9666c4ad3eb906830@HIDDEN>
 <jwvwnst6n9z.fsf-monnier+emacs@HIDDEN>
 <f2b9666c4af5495f32cb@HIDDEN>
 <jwvh7jx6jfn.fsf-monnier+emacs@HIDDEN>
 <f2b9666c4af154b8671e@HIDDEN>
 <jwvh7jw6a6m.fsf-monnier+emacs@HIDDEN>
 <f2b9666c4a0baa3a67e2@HIDDEN>
 <jwvbla44qoy.fsf-monnier+emacs@HIDDEN>
 <7ee648e8400708d266ed@HIDDEN>
Date: Sat, 01 May 2021 15:34:44 -0400
In-Reply-To: <7ee648e8400708d266ed@HIDDEN> (Gregory Heytings's message
 of "Sat, 24 Apr 2021 08:44:38 +0000")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.168 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 45474
Cc: Dario Gjorgjevski <dario.gjorgjevski@HIDDEN>, 45474 <at> debbugs.gnu.org,
 Juri Linkov <juri@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

OK, seeing how noone reported problems with my patch, I pushed it to
`master`.  In case someone later reports a problem, we may "revert" to
your approach if its slightly better compatibility proves useful.


        Stefan


Gregory Heytings [2021-04-24 08:44:38] wrote:

>>> Aren't these problems orthogonal to the problem at hand?  It seems to me
>>> that this is not different from the traditional way of passing arguments
>>> to a function; of course something unexpected can happen when they are
>>> evaluated, before the function is entered, but that's something outside
>>> the responsibility of the function.
>>
>> No, the problem is not "can someone change `minibuffer-completion-table`
>> before we get to its intended consumer" but "will the let-binding of
>> `minibuffer-completion-table` also affect code which was not the intended
>> consumer". This problem does not exist with traditional/explicit
>> argument passing.
>>
>
> Again, it seems to me that this problem is not directly related to the
>  problem at hand.  If the caller of read-from-minibuffer is not careful
>  enough and binds minibuffer-completion-* too far from the call, in such
>  a way that other code is unexpectedly affected (or could unexpectedly be
>  affected) by this binding, it's the responsibility of that caller to fix
>  that problem.
>
> Anyway, I attach a last version of my patch, in which all the dancing
>  happens at the C level.  It is probably also possible to finally get rid of
>  the 15 lines with the minibuffer-completing-file-name = Qlambda hack in
>  read_minibuf().





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45474; Package emacs. Full text available.

Message received at 45474 <at> debbugs.gnu.org:


Received: (at 45474) by debbugs.gnu.org; 24 Apr 2021 08:44:44 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 24 04:44:44 2021
Received: from localhost ([127.0.0.1]:39420 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1laDu7-0008CV-Kl
	for submit <at> debbugs.gnu.org; Sat, 24 Apr 2021 04:44:44 -0400
Received: from heytings.org ([95.142.160.155]:51148)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <gregory@HIDDEN>) id 1laDu5-0008CM-Af
 for 45474 <at> debbugs.gnu.org; Sat, 24 Apr 2021 04:44:42 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org;
 s=20210101; t=1619253879;
 bh=GyUL9Fkzx5TxKGtgvxFgZCeB65VItc53soIY5FSdMVA=;
 h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From;
 b=rHU8TOIqNDAaE3Pa71FhwZ+dQHSxhHVd60AqCpOd380zAr6a3lRSEDELxGobIUIbh
 DdBAQwrmi7TU2JR72xp+tAsx20x+qI3FNZqaFs+SgiyR1K5AUIvMJVMhEQPNrihRkj
 VW77ftNFTUpeAWkSUvKO6J0/xLAIXwyBii4V2wxuHwyYDc+7NUpnmb3LkeAmXAe7o5
 P+Mj3nuGimofd7XPYBKBE3OnuzNnUYpSbHF7zCynm6vwqNOa6B1mkJxyTebNzY8zgZ
 35gw80fFRZ/774uIntWoexNkC3Ed+8iC/i1k2UQQAoCRQp3WtunzOBzG6jpDhcoK+Z
 GJrCBIhI1aMPQ==
Date: Sat, 24 Apr 2021 08:44:38 +0000
From: Gregory Heytings <gregory@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
Subject: =?UTF-8?Q?Re=3A_bug#45474=3A_Icomplete_exhibiting_in_recursive?=
 =?UTF-8?Q?_minibuffer_when_it_shouldn=E2=80=99t?=
In-Reply-To: <jwvbla44qoy.fsf-monnier+emacs@HIDDEN>
Message-ID: <7ee648e8400708d266ed@HIDDEN>
References: <fv2zojtus7b0tz.fsf@HIDDEN>
 <jwvk0p04mbj.fsf-monnier+emacs@HIDDEN> <871rb6np5j.fsf@HIDDEN>
 <jwvczuqrm7s.fsf-monnier+emacs@HIDDEN> <87lf9cepqw.fsf@HIDDEN>
 <jwvsg3iig5h.fsf-monnier+emacs@HIDDEN>
 <jwvbla6if85.fsf-monnier+emacs@HIDDEN>
 <a87041afcb5f214d96a5@HIDDEN> <a87041afcb505462c0d5@HIDDEN>
 <jwv35vigog8.fsf-monnier+emacs@HIDDEN> <a87041afcb4761711a9a@HIDDEN>
 <jwv1rb1dhyu.fsf-monnier+emacs@HIDDEN> <f2b9666c4a7c09220e53@HIDDEN>
 <jwvmttp9mb4.fsf-monnier+emacs@HIDDEN>
 <f2b9666c4ad3eb906830@HIDDEN> <jwvwnst6n9z.fsf-monnier+emacs@HIDDEN>
 <f2b9666c4af5495f32cb@HIDDEN> <jwvh7jx6jfn.fsf-monnier+emacs@HIDDEN>
 <f2b9666c4af154b8671e@HIDDEN> <jwvh7jw6a6m.fsf-monnier+emacs@HIDDEN>
 <f2b9666c4a0baa3a67e2@HIDDEN>
 <jwvbla44qoy.fsf-monnier+emacs@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="2Mj1rrOohc"
Content-ID: <7ee648e84050acecceb1@HIDDEN>
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 45474
Cc: Dario Gjorgjevski <dario.gjorgjevski@HIDDEN>, 45474 <at> debbugs.gnu.org,
 Juri Linkov <juri@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)


--2Mj1rrOohc
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-ID: <7ee648e84081d79ca5e4@HIDDEN>


>> Aren't these problems orthogonal to the problem at hand?  It seems to 
>> me that this is not different from the traditional way of passing 
>> arguments to a function; of course something unexpected can happen when 
>> they are evaluated, before the function is entered, but that's 
>> something outside the responsibility of the function.
>
> No, the problem is not "can someone change `minibuffer-completion-table` 
> before we get to its intended consumer" but "will the let-binding of 
> `minibuffer-completion-table` also affect code which was not the 
> intended consumer". This problem does not exist with 
> traditional/explicit argument passing.
>

Again, it seems to me that this problem is not directly related to the 
problem at hand.  If the caller of read-from-minibuffer is not careful 
enough and binds minibuffer-completion-* too far from the call, in such a 
way that other code is unexpectedly affected (or could unexpectedly be 
affected) by this binding, it's the responsibility of that caller to fix 
that problem.

Anyway, I attach a last version of my patch, in which all the dancing 
happens at the C level.  It is probably also possible to finally get rid 
of the 15 lines with the minibuffer-completing-file-name = Qlambda hack in 
read_minibuf().
--2Mj1rrOohc
Content-Type: text/x-diff; name=Make-it-possible-to-disable-a-completion-backend-in-.patch
Content-Transfer-Encoding: base64
Content-ID: <7ee648e840010b4d7cfb@HIDDEN>
Content-Description: 
Content-Disposition: attachment; filename=Make-it-possible-to-disable-a-completion-backend-in-.patch

RnJvbSAzM2RjZGQ2ZWE5OTJlODg2MTRiYWE3N2I0MmMzZTUzYmY5ZjZhMDhh
IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQ0KRnJvbTogR3JlZ29yeSBIZXl0
aW5ncyA8Z3JlZ29yeUBoZXl0aW5ncy5vcmc+DQpEYXRlOiBTYXQsIDI0IEFw
ciAyMDIxIDA4OjQzOjQ1ICswMDAwDQpTdWJqZWN0OiBbUEFUQ0hdIE1ha2Ug
aXQgcG9zc2libGUgdG8gZGlzYWJsZSBhIGNvbXBsZXRpb24gYmFja2VuZCBp
biByZWN1cnNpdmUNCiBtaW5pYnVmZmVycw0KDQotLS0NCiBsaXNwL21pbmli
dWZmZXIuZWwgfCAgMyArKy0NCiBzcmMvbWluaWJ1Zi5jICAgICAgfCA0OSAr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKystLS0t
DQogMiBmaWxlcyBjaGFuZ2VkLCA0NyBpbnNlcnRpb25zKCspLCA1IGRlbGV0
aW9ucygtKQ0KDQpkaWZmIC0tZ2l0IGEvbGlzcC9taW5pYnVmZmVyLmVsIGIv
bGlzcC9taW5pYnVmZmVyLmVsDQppbmRleCA3ZGEzYzM5ZTZiLi4zNzlkYWRl
ZjlkIDEwMDY0NA0KLS0tIGEvbGlzcC9taW5pYnVmZmVyLmVsDQorKysgYi9s
aXNwL21pbmlidWZmZXIuZWwNCkBAIC0zODg0LDcgKzM4ODQsOCBAQCBjb21w
bGV0aW5nLXJlYWQtZGVmYXVsdA0KICAgICAgICAgICAgICAgICA7OyBgcmVh
ZC1mcm9tLW1pbmlidWZmZXInIHVzZXMgMS1iYXNlZCBpbmRleC4NCiAgICAg
ICAgICAgICAgICAgKDErIChjZHIgaW5pdGlhbC1pbnB1dCkpKSkpDQogDQot
ICAobGV0KiAoKG1pbmlidWZmZXItY29tcGxldGlvbi10YWJsZSBjb2xsZWN0
aW9uKQ0KKyAgKGxldCogKChtaW5pYnVmZmVyLWxvY2FsLWNvbXBsZXRpb24g
dCkNCisgICAgICAgICAobWluaWJ1ZmZlci1jb21wbGV0aW9uLXRhYmxlIGNv
bGxlY3Rpb24pDQogICAgICAgICAgKG1pbmlidWZmZXItY29tcGxldGlvbi1w
cmVkaWNhdGUgcHJlZGljYXRlKQ0KICAgICAgICAgIDs7IEZJWE1FOiBSZW1v
dmUvcmVuYW1lIHRoaXMgdmFyLCBzZWUgdGhlIG5leHQgb25lLg0KICAgICAg
ICAgIChtaW5pYnVmZmVyLWNvbXBsZXRpb24tY29uZmlybSAodW5sZXNzIChl
cSByZXF1aXJlLW1hdGNoIHQpDQpkaWZmIC0tZ2l0IGEvc3JjL21pbmlidWYu
YyBiL3NyYy9taW5pYnVmLmMNCmluZGV4IGM0NDgyZDdmMWUuLmQwYjgwNGNk
ZmYgMTAwNjQ0DQotLS0gYS9zcmMvbWluaWJ1Zi5jDQorKysgYi9zcmMvbWlu
aWJ1Zi5jDQpAQCAtNjgsNiArNjgsOSBAQCBDb3B5cmlnaHQgKEMpIDE5ODUt
MTk4NiwgMTk5My0yMDIxIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbiwgSW5j
Lg0KIC8qIFdpZHRoIG9mIGN1cnJlbnQgbWluaS1idWZmZXIgcHJvbXB0LiAg
T25seSBzZXQgYWZ0ZXIgZGlzcGxheV9saW5lDQogICAgb2YgdGhlIGxpbmUg
dGhhdCBjb250YWlucyB0aGUgcHJvbXB0LiAgKi8NCiANCitzdGF0aWMgTGlz
cF9PYmplY3QgbWluaWJ1ZmZlcl9jb21wbGV0aW9uX3RhYmxlLCBtaW5pYnVm
ZmVyX2NvbXBsZXRpb25fcHJlZGljYXRlLA0KKyAgbWluaWJ1ZmZlcl9jb21w
bGV0aW9uX2NvbmZpcm07DQorDQogc3RhdGljIHB0cmRpZmZfdCBtaW5pYnVm
X3Byb21wdF93aWR0aDsNCiANCiBzdGF0aWMgTGlzcF9PYmplY3QgbnRoX21p
bmlidWZmZXIgKEVNQUNTX0lOVCBkZXB0aCk7DQpAQCAtODYyLDYgKzg2NSwx
NiBAQCByZWFkX21pbmlidWYgKExpc3BfT2JqZWN0IG1hcCwgTGlzcF9PYmpl
Y3QgaW5pdGlhbCwgTGlzcF9PYmplY3QgcHJvbXB0LA0KICAgaWYgKFNUUklO
R1AgKGlucHV0X21ldGhvZCkgJiYgIU5JTFAgKEZmYm91bmRwIChRYWN0aXZh
dGVfaW5wdXRfbWV0aG9kKSkpDQogICAgIGNhbGwxIChRYWN0aXZhdGVfaW5w
dXRfbWV0aG9kLCBpbnB1dF9tZXRob2QpOw0KIA0KKyAgaWYgKCEgRVEgKFZt
aW5pYnVmZmVyX2xvY2FsX2NvbXBsZXRpb24sIFFuaWwpKSB7DQorICAgIEZt
YWtlX2xvY2FsX3ZhcmlhYmxlIChRbWluaWJ1ZmZlcl9jb21wbGV0aW9uX3Rh
YmxlKTsNCisgICAgRnNldCAoUW1pbmlidWZmZXJfY29tcGxldGlvbl90YWJs
ZSwgbWluaWJ1ZmZlcl9jb21wbGV0aW9uX3RhYmxlKTsNCisgICAgRm1ha2Vf
bG9jYWxfdmFyaWFibGUgKFFtaW5pYnVmZmVyX2NvbXBsZXRpb25fcHJlZGlj
YXRlKTsNCisgICAgRnNldCAoUW1pbmlidWZmZXJfY29tcGxldGlvbl9wcmVk
aWNhdGUsIG1pbmlidWZmZXJfY29tcGxldGlvbl9wcmVkaWNhdGUpOw0KKyAg
ICBGbWFrZV9sb2NhbF92YXJpYWJsZSAoUW1pbmlidWZmZXJfY29tcGxldGlv
bl9jb25maXJtKTsNCisgICAgRnNldCAoUW1pbmlidWZmZXJfY29tcGxldGlv
bl9jb25maXJtLCBtaW5pYnVmZmVyX2NvbXBsZXRpb25fY29uZmlybSk7DQor
ICAgIFZtaW5pYnVmZmVyX2xvY2FsX2NvbXBsZXRpb24gPSBRbmlsOw0KKyAg
fQ0KKw0KICAgcnVuX2hvb2sgKFFtaW5pYnVmZmVyX3NldHVwX2hvb2spOw0K
IA0KICAgLyogRG9uJ3QgYWxsb3cgdGhlIHVzZXIgdG8gdW5kbyBwYXN0IHRo
aXMgcG9pbnQuICAqLw0KQEAgLTEyOTEsNiArMTMwNCw3IEBAIERFRlVOICgi
cmVhZC1mcm9tLW1pbmlidWZmZXIiLCBGcmVhZF9mcm9tX21pbmlidWZmZXIs
DQogICAoTGlzcF9PYmplY3QgcHJvbXB0LCBMaXNwX09iamVjdCBpbml0aWFs
X2NvbnRlbnRzLCBMaXNwX09iamVjdCBrZXltYXAsIExpc3BfT2JqZWN0IHJl
YWQsIExpc3BfT2JqZWN0IGhpc3QsIExpc3BfT2JqZWN0IGRlZmF1bHRfdmFs
dWUsIExpc3BfT2JqZWN0IGluaGVyaXRfaW5wdXRfbWV0aG9kKQ0KIHsNCiAg
IExpc3BfT2JqZWN0IGhpc3R2YXIsIGhpc3Rwb3MsIHZhbDsNCisgIHB0cmRp
ZmZfdCBjb3VudDsNCiANCiAgIGJhcmZfaWZfaW50ZXJhY3Rpb25faW5oaWJp
dGVkICgpOw0KIA0KQEAgLTEzMTUsMTEgKzEzMjksMjUgQEAgREVGVU4gKCJy
ZWFkLWZyb20tbWluaWJ1ZmZlciIsIEZyZWFkX2Zyb21fbWluaWJ1ZmZlciwN
CiAgIGlmIChOSUxQIChoaXN0cG9zKSkNCiAgICAgWFNFVEZBU1RJTlQgKGhp
c3Rwb3MsIDApOw0KIA0KKyAgY291bnQgPSBTUEVDUERMX0lOREVYICgpOw0K
Kw0KKyAgaWYgKCEgRVEgKFZtaW5pYnVmZmVyX2xvY2FsX2NvbXBsZXRpb24s
IFFuaWwpKSB7DQorICAgIG1pbmlidWZmZXJfY29tcGxldGlvbl90YWJsZSA9
IFZtaW5pYnVmZmVyX2NvbXBsZXRpb25fdGFibGU7DQorICAgIG1pbmlidWZm
ZXJfY29tcGxldGlvbl9wcmVkaWNhdGUgPSBWbWluaWJ1ZmZlcl9jb21wbGV0
aW9uX3ByZWRpY2F0ZTsNCisgICAgbWluaWJ1ZmZlcl9jb21wbGV0aW9uX2Nv
bmZpcm0gPSBWbWluaWJ1ZmZlcl9jb21wbGV0aW9uX2NvbmZpcm07DQorICAg
IHNwZWNiaW5kIChRbWluaWJ1ZmZlcl9jb21wbGV0aW9uX3RhYmxlLCBRbmls
KTsNCisgICAgc3BlY2JpbmQgKFFtaW5pYnVmZmVyX2NvbXBsZXRpb25fcHJl
ZGljYXRlLCBRbmlsKTsNCisgICAgc3BlY2JpbmQgKFFtaW5pYnVmZmVyX2Nv
bXBsZXRpb25fY29uZmlybSwgUW5pbCk7DQorICB9DQorDQogICB2YWwgPSBy
ZWFkX21pbmlidWYgKGtleW1hcCwgaW5pdGlhbF9jb250ZW50cywgcHJvbXB0
LA0KIAkJICAgICAgIU5JTFAgKHJlYWQpLA0KIAkJICAgICAgaGlzdHZhciwg
aGlzdHBvcywgZGVmYXVsdF92YWx1ZSwNCiAJCSAgICAgIG1pbmlidWZmZXJf
YWxsb3dfdGV4dF9wcm9wZXJ0aWVzLA0KIAkJICAgICAgIU5JTFAgKGluaGVy
aXRfaW5wdXRfbWV0aG9kKSk7DQorDQorICB1bmJpbmRfdG8gKGNvdW50LCBR
bmlsKTsNCisNCiAgIHJldHVybiB2YWw7DQogfQ0KIA0KQEAgLTEzNDUsMTEg
KzEzNzMsOSBAQCBERUZVTiAoInJlYWQtc3RyaW5nIiwgRnJlYWRfc3RyaW5n
LCBTcmVhZF9zdHJpbmcsIDEsIDUsIDAsDQogICBMaXNwX09iamVjdCB2YWw7
DQogICBwdHJkaWZmX3QgY291bnQgPSBTUEVDUERMX0lOREVYICgpOw0KIA0K
LSAgLyogSnVzdCBpbiBjYXNlIHdlJ3JlIGluIGEgcmVjdXJzaXZlIG1pbmli
dWZmZXIsIG1ha2UgaXQgY2xlYXIgdGhhdCB0aGUNCi0gICAgIHByZXZpb3Vz
IG1pbmlidWZmZXIncyBjb21wbGV0aW9uIHRhYmxlIGRvZXMgbm90IGFwcGx5
IHRvIHRoZSBuZXcNCi0gICAgIG1pbmlidWZmZXIuDQotICAgICBGSVhNRTog
YG1pbmlidWZmZXItY29tcGxldGlvbi10YWJsZScgc2hvdWxkIGJlIGJ1ZmZl
ci1sb2NhbCBpbnN0ZWFkLiAgKi8NCiAgIHNwZWNiaW5kIChRbWluaWJ1ZmZl
cl9jb21wbGV0aW9uX3RhYmxlLCBRbmlsKTsNCisgIHNwZWNiaW5kIChRbWlu
aWJ1ZmZlcl9jb21wbGV0aW9uX3ByZWRpY2F0ZSwgUW5pbCk7DQorICBzcGVj
YmluZCAoUW1pbmlidWZmZXJfY29tcGxldGlvbl9jb25maXJtLCBRbmlsKTsN
CiANCiAgIHZhbCA9IEZyZWFkX2Zyb21fbWluaWJ1ZmZlciAocHJvbXB0LCBp
bml0aWFsX2lucHV0LCBRbmlsLA0KIAkJCSAgICAgICBRbmlsLCBoaXN0b3J5
LCBkZWZhdWx0X3ZhbHVlLA0KQEAgLTIyODEsNiArMjMwNyw5IEBAIHN5bXNf
b2ZfbWluaWJ1ZiAodm9pZCkNCiAgIEZzZXQgKFFtaW5pYnVmZmVyX2RlZmF1
bHQsIFFuaWwpOw0KIA0KICAgREVGU1lNIChRbWluaWJ1ZmZlcl9jb21wbGV0
aW9uX3RhYmxlLCAibWluaWJ1ZmZlci1jb21wbGV0aW9uLXRhYmxlIik7DQor
ICBERUZTWU0gKFFtaW5pYnVmZmVyX2NvbXBsZXRpb25fcHJlZGljYXRlLCAi
bWluaWJ1ZmZlci1jb21wbGV0aW9uLXByZWRpY2F0ZSIpOw0KKyAgREVGU1lN
IChRbWluaWJ1ZmZlcl9jb21wbGV0aW9uX2NvbmZpcm0sICJtaW5pYnVmZmVy
LWNvbXBsZXRpb24tY29uZmlybSIpOw0KKyAgREVGU1lNIChRbWluaWJ1ZmZl
cl9sb2NhbF9jb21wbGV0aW9uLCAibWluaWJ1ZmZlci1sb2NhbC1jb21wbGV0
aW9uIik7DQogDQogICBzdGF0aWNwcm8gKCZsYXN0X21pbmlidWZfc3RyaW5n
KTsNCiANCkBAIC0yNDE0LDYgKzI0NDMsMTggQEAgc3ltc19vZl9taW5pYnVm
ICh2b2lkKQ0KICBjb21wbGV0aW9uIGNvbW1hbmRzIGxpc3RlZCBpbiBgbWlu
aWJ1ZmZlci1jb25maXJtLWV4aXQtY29tbWFuZHMnLiAgKi8pOw0KICAgVm1p
bmlidWZmZXJfY29tcGxldGlvbl9jb25maXJtID0gUW5pbDsNCiANCisgIERF
RlZBUl9MSVNQICgibWluaWJ1ZmZlci1sb2NhbC1jb21wbGV0aW9uIiwgVm1p
bmlidWZmZXJfbG9jYWxfY29tcGxldGlvbiwNCisJICAgICAgIGRvYzogLyog
V2hldGhlciBtaW5pYnVmZmVyIGNvbXBsZXRpb24gZWxlbWVudHMgc2hvdWxk
IGJlY29tZSBidWZmZXItbG9jYWwuDQorVGhlIGRlZmF1bHQgaXMgbmlsIGZv
ciBFbWFjcyAyOC4gIFNldHRpbmcgdGhpcyB2YXJpYWJsZSBpbiBFbWFjcyAy
OSB3aWxsIGhhdmUgbm8gZWZmZWN0Ow0KK3RoZSB2YWx1ZSB0IHdpbGwgYmUg
YXNzdW1lZC4NCitXaGVuIHQsIGBtaW5pYnVmZmVyLWNvbXBsZXRpb24tdGFi
bGUnLCBgbWluaWJ1ZmZlci1jb21wbGV0aW9uLXByZWRpY2F0ZScgYW5kDQor
YG1pbmlidWZmZXItY29tcGxldGlvbi1jb25maXJtJyBiZWNvbWUgYnVmZmVy
LWxvY2FsIHVwb24gZW50ZXJpbmcgdGhlIG1pbmlidWZmZXIsDQorYW5kIGFy
ZSBuaWwgaW4gcmVjdXJzaXZlIGludm9jYXRpb25zIG9mIHRoZSBtaW5pYnVm
ZmVyLCB1bmxlc3MgdGhleSBoYXZlIGJlZW4gbGV0LWJvdW5kDQordG8gYSB2
YWx1ZS4NCitXaGVuIG5pbCwgdGhlaXIgdmFsdWVzIGlzIHNoYXJlZCBiZXR3
ZWVuIHRoZSByZWN1cnNpdmUgaW52b2NhdGlvbnMgb2YgdGhlIG1pbmlidWZm
ZXIsDQordW5sZXNzIHRoZXkgaGF2ZSBiZWVuIGxldC1ib3VuZCB0byBhbm90
aGVyIHZhbHVlLiAgKi8pOw0KKyAgVm1pbmlidWZmZXJfbG9jYWxfY29tcGxl
dGlvbiA9IFFuaWw7DQorDQogICBERUZWQVJfTElTUCAoIm1pbmlidWZmZXIt
Y29tcGxldGluZy1maWxlLW5hbWUiLA0KIAkgICAgICAgVm1pbmlidWZmZXJf
Y29tcGxldGluZ19maWxlX25hbWUsDQogCSAgICAgICBkb2M6IC8qIE5vbi1u
aWwgbWVhbnMgY29tcGxldGluZyBmaWxlIG5hbWVzLiAgKi8pOw0KLS0gDQoy
LjMwLjINCg0K

--2Mj1rrOohc--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45474; Package emacs. Full text available.

Message received at 45474 <at> debbugs.gnu.org:


Received: (at 45474) by debbugs.gnu.org; 23 Apr 2021 21:54:43 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Apr 23 17:54:43 2021
Received: from localhost ([127.0.0.1]:39094 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1la3l4-0001DX-QP
	for submit <at> debbugs.gnu.org; Fri, 23 Apr 2021 17:54:43 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:9679)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1la3l2-0001DK-PV
 for 45474 <at> debbugs.gnu.org; Fri, 23 Apr 2021 17:54:41 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id DD7AC1001FE;
 Fri, 23 Apr 2021 17:54:34 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 2D57510006B;
 Fri, 23 Apr 2021 17:54:33 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1619214873;
 bh=V6XesJc2WasywuCzMPODNBVUctu40eUyyRiR5z5ZY4g=;
 h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
 b=EcLYcitFtjpI2PECJ4U/Vi9nfYRKxQQLXPwUG1ek3JMD2u4dJRFcfeg8PRfzciPSx
 kqqMEsFpL2YjnVFFiaH+3jizpYhlt71Vf1cB1x+Nl8esaV5LbyhPo6pTsPkV7CsVOM
 5ZJvBL4xzaZgxmJpxH75/ZpMNLqrHSmOJ62U1/u4PieLiQL1d09SPWkpXIK+cSn0Mh
 +Yd1oSie7j38/zk8kyw7vc6o7uG+9Cl52LML6a7I3r0zg6MeekTpCCqWeZpqDK27cf
 L6EAJpklgTQnLzvSO8zSdgUPIaKhKbRHu3fcJ3RQ8XvoEL6aCWfDUD7xQKSe/NpD5F
 TfponaVwcZ92w==
Received: from alfajor (104-222-126-84.cpe.teksavvy.com [104.222.126.84])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id D3E5D1201C9;
 Fri, 23 Apr 2021 17:54:32 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Gregory Heytings <gregory@HIDDEN>
Subject: Re: bug#45474: Icomplete exhibiting in recursive minibuffer when it
 =?utf-8?Q?shouldn=E2=80=99t?=
Message-ID: <jwvbla44qoy.fsf-monnier+emacs@HIDDEN>
References: <fv2zojtus7b0tz.fsf@HIDDEN>
 <jwvk0p04mbj.fsf-monnier+emacs@HIDDEN>
 <871rb6np5j.fsf@HIDDEN>
 <jwvczuqrm7s.fsf-monnier+emacs@HIDDEN>
 <87lf9cepqw.fsf@HIDDEN>
 <jwvsg3iig5h.fsf-monnier+emacs@HIDDEN>
 <jwvbla6if85.fsf-monnier+emacs@HIDDEN>
 <a87041afcb5f214d96a5@HIDDEN>
 <a87041afcb505462c0d5@HIDDEN>
 <jwv35vigog8.fsf-monnier+emacs@HIDDEN>
 <a87041afcb4761711a9a@HIDDEN>
 <jwv1rb1dhyu.fsf-monnier+emacs@HIDDEN>
 <f2b9666c4a7c09220e53@HIDDEN>
 <jwvmttp9mb4.fsf-monnier+emacs@HIDDEN>
 <f2b9666c4ad3eb906830@HIDDEN>
 <jwvwnst6n9z.fsf-monnier+emacs@HIDDEN>
 <f2b9666c4af5495f32cb@HIDDEN>
 <jwvh7jx6jfn.fsf-monnier+emacs@HIDDEN>
 <f2b9666c4af154b8671e@HIDDEN>
 <jwvh7jw6a6m.fsf-monnier+emacs@HIDDEN>
 <f2b9666c4a0baa3a67e2@HIDDEN>
Date: Fri, 23 Apr 2021 17:54:30 -0400
In-Reply-To: <f2b9666c4a0baa3a67e2@HIDDEN> (Gregory Heytings's message
 of "Fri, 23 Apr 2021 21:36:31 +0000")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.036 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 45474
Cc: Dario Gjorgjevski <dario.gjorgjevski@HIDDEN>, 45474 <at> debbugs.gnu.org,
 Juri Linkov <juri@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

>>> Indeed, but... it doesn't help/incite them to move forward in the "right"
>>> direction, to finally have what has been on wishlist for quite a long
>>> time: to have buffer-local minibuffer-completion-* elements...
>> It helps by showing how to do it.  I haven't seen any proposal here which
>> helps further than that (except maybe for some proposals which might break
>> such code, thus inciting them to use a better approach ;-).
> I believe that creating an optional behavior that is easy to use, and
> stating that that behavior will become mandatory in the next major Emacs
> release, is a stronger incentive.

We could add some "break old code" option, indeed.
I think we can do that with pretty much all the proposed patches.
We could also add a "warn when detecting old code" option; again
I suspect that this can be done with most of the proposed patches so far.
So, it's rather orthogonal to the choice of which approach is preferable.

>>> But when the let-bindings are in a macro the caller doesn't have to care
>>> with them, and they are indeed happening as close as possible to
>>> internal-read-from-minibuffer.
>> AFAICT you're talking about the let-bindings of `minibuffer-local-*`
>> whereas the problematic let-bindings are those of
>> `minibuffer-completion-*` and those are outside of `read-from-minibuffer`.
> Aren't these problems orthogonal to the problem at hand?  It seems to me
> that this is not different from the traditional way of passing arguments to
> a function; of course something unexpected can happen when they are
> evaluated, before the function is entered, but that's something outside the
> responsibility of the function.

No, the problem is not "can someone change `minibuffer-completion-table`
before we get to its intended consumer" but "will the let-binding of
`minibuffer-completion-table` also affect code which was not the
intended consumer".
This problem does not exist with traditional/explicit argument passing.

> My aim here was to (help to) fix the nine years old "FIXME:
> `minibuffer-completion-table' should be buffer-local instead."  What would
> you do to fix it, in an ideal world in which backward compatibility is not
> an issue?

The patch I sent does just that.


        Stefan





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45474; Package emacs. Full text available.

Message received at 45474 <at> debbugs.gnu.org:


Received: (at 45474) by debbugs.gnu.org; 23 Apr 2021 21:36:34 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Apr 23 17:36:34 2021
Received: from localhost ([127.0.0.1]:39059 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1la3TW-0000lp-G1
	for submit <at> debbugs.gnu.org; Fri, 23 Apr 2021 17:36:34 -0400
Received: from heytings.org ([95.142.160.155]:50650)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <gregory@HIDDEN>) id 1la3TU-0000lh-QH
 for 45474 <at> debbugs.gnu.org; Fri, 23 Apr 2021 17:36:33 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org;
 s=20210101; t=1619213791;
 bh=pHWfvH71cUWL5NAYxpCwWvmMqVxiUsWERqBjqU4Sy7c=;
 h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From;
 b=XhU9etqiEvCXv1wXdKmt3PWjrHkvqLNGjTV3iSTPM0Veep7wQOV7obzeC16SeLQHM
 eUvGRWTIjJXY/seXhVgoQziHLNpHUndEt3yiRSSXR+AbDkbe+/J3Oohk/xReKYip9P
 21Y8dupwpruikGVcTtA5HYy7nt93JGrrKq7CKQbjkgJWF9XgCoSDT38KpMGbJfee00
 rAbI3A0KKBSm66Q30BK4VhAFTa5KC+34x0aWrcJ3XD4sXwMKXpkk6ZYhScpBOaGAln
 Gp63M2Xz8Dk5QQ8BHmU4saniopn1Q8lkYYgn4Mrj4EWS1AwB/0QjsrbkcO/fJ2aWPG
 rGUTs9EMFioUA==
Date: Fri, 23 Apr 2021 21:36:31 +0000
From: Gregory Heytings <gregory@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
Subject: =?UTF-8?Q?Re=3A_bug#45474=3A_Icomplete_exhibiting_in_recursive?=
 =?UTF-8?Q?_minibuffer_when_it_shouldn=E2=80=99t?=
In-Reply-To: <jwvh7jw6a6m.fsf-monnier+emacs@HIDDEN>
Message-ID: <f2b9666c4a0baa3a67e2@HIDDEN>
References: <fv2zojtus7b0tz.fsf@HIDDEN> <87im4kzlfm.fsf@HIDDEN>
 <1869622e16546eafd9df@HIDDEN> <jwvk0p04mbj.fsf-monnier+emacs@HIDDEN>
 <871rb6np5j.fsf@HIDDEN> <jwvczuqrm7s.fsf-monnier+emacs@HIDDEN>
 <87lf9cepqw.fsf@HIDDEN>
 <jwvsg3iig5h.fsf-monnier+emacs@HIDDEN>
 <jwvbla6if85.fsf-monnier+emacs@HIDDEN> <a87041afcb5f214d96a5@HIDDEN>
 <a87041afcb505462c0d5@HIDDEN> <jwv35vigog8.fsf-monnier+emacs@HIDDEN>
 <a87041afcb4761711a9a@HIDDEN> <jwv1rb1dhyu.fsf-monnier+emacs@HIDDEN>
 <f2b9666c4a7c09220e53@HIDDEN> <jwvmttp9mb4.fsf-monnier+emacs@HIDDEN>
 <f2b9666c4ad3eb906830@HIDDEN> <jwvwnst6n9z.fsf-monnier+emacs@HIDDEN>
 <f2b9666c4af5495f32cb@HIDDEN> <jwvh7jx6jfn.fsf-monnier+emacs@HIDDEN>
 <f2b9666c4af154b8671e@HIDDEN>
 <jwvh7jw6a6m.fsf-monnier+emacs@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset=us-ascii
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 45474
Cc: Dario Gjorgjevski <dario.gjorgjevski@HIDDEN>, 45474 <at> debbugs.gnu.org,
 Juri Linkov <juri@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)


>> Indeed, but... it doesn't help/incite them to move forward in the 
>> "right" direction, to finally have what has been on wishlist for quite 
>> a long time: to have buffer-local minibuffer-completion-* elements...
>
> It helps by showing how to do it.  I haven't seen any proposal here 
> which helps further than that (except maybe for some proposals which 
> might break such code, thus inciting them to use a better approach ;-).
>

I believe that creating an optional behavior that is easy to use, and 
stating that that behavior will become mandatory in the next major Emacs 
release, is a stronger incentive.

>> But when the let-bindings are in a macro the caller doesn't have to 
>> care with them, and they are indeed happening as close as possible to 
>> internal-read-from-minibuffer.
>
> AFAICT you're talking about the let-bindings of `minibuffer-local-*` 
> whereas the problematic let-bindings are those of 
> `minibuffer-completion-*` and those are outside of 
> `read-from-minibuffer`.
>

Aren't these problems orthogonal to the problem at hand?  It seems to me 
that this is not different from the traditional way of passing arguments 
to a function; of course something unexpected can happen when they are 
evaluated, before the function is entered, but that's something outside 
the responsibility of the function.

My aim here was to (help to) fix the nine years old "FIXME: 
`minibuffer-completion-table' should be buffer-local instead."  What would 
you do to fix it, in an ideal world in which backward compatibility is not 
an issue?




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45474; Package emacs. Full text available.

Message received at 45474 <at> debbugs.gnu.org:


Received: (at 45474) by debbugs.gnu.org; 23 Apr 2021 20:24:50 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Apr 23 16:24:50 2021
Received: from localhost ([127.0.0.1]:38967 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1la2M5-0007Sx-ST
	for submit <at> debbugs.gnu.org; Fri, 23 Apr 2021 16:24:50 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:23339)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1la2M4-0007Sl-Dm
 for 45474 <at> debbugs.gnu.org; Fri, 23 Apr 2021 16:24:48 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id E0B4080931;
 Fri, 23 Apr 2021 16:24:42 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 8A775801AB;
 Fri, 23 Apr 2021 16:24:36 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1619209476;
 bh=7boCtwFg/6BDejRL2HffxqoFAQWaye2Bgtn36VjlbZU=;
 h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
 b=lv0dLKPXRyEwKy8cI7MRJZhwjHOyWKZaHrLvMqThRLjdEL4WWLGSMCsA4j/bMybcG
 BM07GJD2d1K9064OG1rxuofpDeRVL6j71GU/luhbjZm/Mnyd9RW3FP32A+UHwzIv+s
 rNMXrfnsDDCGB2ExDM/2SCAu+BsO8nv/n95pLN/gn9hzebNDgkEqWepJs/MdRpivnV
 iiYSOtrihIo2ly/WB3j0ly477PfsjGXrrg7k77b8jwRDwqCuC8MigxWsFP2Am5SRmN
 LS/wyUN7KCcX80aF/pScLgkpxPag012anT7IAKO730ZdPr+2Mc8MevBN917a7WBTR5
 442Cznt/GL8nQ==
Received: from alfajor (104-222-126-84.cpe.teksavvy.com [104.222.126.84])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 47B1312026E;
 Fri, 23 Apr 2021 16:24:36 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Gregory Heytings <gregory@HIDDEN>
Subject: Re: bug#45474: Icomplete exhibiting in recursive minibuffer when it
 =?utf-8?Q?shouldn=E2=80=99t?=
Message-ID: <jwvh7jw6a6m.fsf-monnier+emacs@HIDDEN>
References: <fv2zojtus7b0tz.fsf@HIDDEN> <87im4kzlfm.fsf@HIDDEN>
 <1869622e16546eafd9df@HIDDEN>
 <jwvk0p04mbj.fsf-monnier+emacs@HIDDEN>
 <871rb6np5j.fsf@HIDDEN>
 <jwvczuqrm7s.fsf-monnier+emacs@HIDDEN>
 <87lf9cepqw.fsf@HIDDEN>
 <jwvsg3iig5h.fsf-monnier+emacs@HIDDEN>
 <jwvbla6if85.fsf-monnier+emacs@HIDDEN>
 <a87041afcb5f214d96a5@HIDDEN>
 <a87041afcb505462c0d5@HIDDEN>
 <jwv35vigog8.fsf-monnier+emacs@HIDDEN>
 <a87041afcb4761711a9a@HIDDEN>
 <jwv1rb1dhyu.fsf-monnier+emacs@HIDDEN>
 <f2b9666c4a7c09220e53@HIDDEN>
 <jwvmttp9mb4.fsf-monnier+emacs@HIDDEN>
 <f2b9666c4ad3eb906830@HIDDEN>
 <jwvwnst6n9z.fsf-monnier+emacs@HIDDEN>
 <f2b9666c4af5495f32cb@HIDDEN>
 <jwvh7jx6jfn.fsf-monnier+emacs@HIDDEN>
 <f2b9666c4af154b8671e@HIDDEN>
Date: Fri, 23 Apr 2021 16:24:34 -0400
In-Reply-To: <f2b9666c4af154b8671e@HIDDEN> (Gregory Heytings's message
 of "Fri, 23 Apr 2021 18:13:21 +0000")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.059 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 45474
Cc: Dario Gjorgjevski <dario.gjorgjevski@HIDDEN>, 45474 <at> debbugs.gnu.org,
 Juri Linkov <juri@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

>>> Well, the fact that there were a few other pieces of code which do that
>>> was (at least as I understood it) part of the initial problem.  And the
>>> purpose of the discussion (at least as I understood it) was to solve the
>>> current problem without breaking these few other pieces of code.
>> Indeed, and I think my patch should by and large leave them unaffected (it
>> neither magically fixes them nor breaks them).
> Indeed, but... it doesn't help/incite them to move forward in the "right"
> direction, to finally have what has been on wishlist for quite a long time:
> to have buffer-local minibuffer-completion-* elements...

It helps by showing how to do it.  I haven't seen any proposal here
which helps further than that (except maybe for some proposals which
might break such code, thus inciting them to use a better approach ;-).

>>> I admit that you lost me here.  What are these [SOMETHINGn]'s, and why
>>> are they happening?
>> Because inevitably code can run in there, e.g. because the debugger gets
>> triggered in there or because the caller of `read-from-minibuffer` was not
>> careful to place the let-bindings of `minibuffer-completion-*` as close as
>> possible to `read-from-minibuffer`.
> I see.  But when the let-bindings are in a macro the caller doesn't have to
> care with them, and they are indeed happening as close as possible to
> internal-read-from-minibuffer.

AFAICT you're talking about the let-bindings of `minibuffer-local-*`
whereas the problematic let-bindings are those of
`minibuffer-completion-*` and those are outside of
`read-from-minibuffer`.

> I didn't know that ELC files had to be backward-compatible between major
> releases.

We don't guarantee such compatibility 100%, but we do our best, and it's
pretty easy to avoid the problem here, so turning `read-from-minibuffer`
into a macro would not qualify as "do our best", I think.

> That being said, my preference would be to have the whole dancing
> happening at the C level (inside read_from_minibuffer and/or read_minibuf),
> which would solve that problem/these problems.

The [SOMETHINGn] are still outside of `read-from-minibuffer` so the
implementation of `read-from-minibuffer` doesn't affect the
problem, really.

> No worries ;-)  Now I see what you mean, and I do not see where you see
> a potential problem there: whether the minibuffer-completion-* elements
> become buffer-local depends on the minibuffer-local-completion
> variable. When it is nil (the default), they do not become buffer-local, and
> the behavior of read-from-minibuffer is the same as earlier.  This gives
> external package plenty of time to adapt their code to the future
> minibuffer-local-completion = t situation.

No, I'm talking about external packages for example those working like
`icomplete-mode`: they don't change the code which sets
`minibuffer-completion-table`, they just look for the completion table
in `minibuffer-completion-table`.  Currently such packages can access
`minibuffer-completion-table` from any buffer.
With our patches this is not the case any more: they can only access it
from the minibuffer.

So far I haven't found such code, tho, so maybe the risk of breakage is
actually much less severe than I imagined.  In any case, this is risk is
the same for both patches.


        Stefan





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45474; Package emacs. Full text available.

Message received at 45474 <at> debbugs.gnu.org:


Received: (at 45474) by debbugs.gnu.org; 23 Apr 2021 18:13:25 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Apr 23 14:13:25 2021
Received: from localhost ([127.0.0.1]:38794 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1la0Iv-0004Cp-0U
	for submit <at> debbugs.gnu.org; Fri, 23 Apr 2021 14:13:25 -0400
Received: from heytings.org ([95.142.160.155]:50460)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <gregory@HIDDEN>) id 1la0It-0004Cg-1L
 for 45474 <at> debbugs.gnu.org; Fri, 23 Apr 2021 14:13:23 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org;
 s=20210101; t=1619201601;
 bh=tbUK6WxhyZ2fkXkX69xRBtR1bOKdTbUasaFv+zxkNrw=;
 h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From;
 b=Wbsgr3qpSy8fefyZ/vrn3Rt3C17FClssOGmuobm2X7K7ArIkctH9kUfguvh0SaWqP
 8N8jSFuYyMHGDf8BDuEsUK/jDyLI5+tBVlR9d8JSaTmzR+DFF2yPatpekgXwXgrN49
 duXayQcNGWRCFIisFFRgDzheQu6I0ebNL2tbegcuiTVseuR28Xriqnf7m00YVmFJPv
 igzAOebc9J3Dud1jaqr4r7nZdAiNzp8fRY04Q69GEgoc0bCzPQxXv6wxSwFxx7py1w
 lCy6uZooUt8pTuyvNKfOZ4LwOsHkR7hp7H7N1oQxerQIwcub0EkUG/Zg2CinWA2gfn
 RzsqybeuGjEDw==
Date: Fri, 23 Apr 2021 18:13:21 +0000
From: Gregory Heytings <gregory@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
Subject: =?UTF-8?Q?Re=3A_bug#45474=3A_Icomplete_exhibiting_in_recursive?=
 =?UTF-8?Q?_minibuffer_when_it_shouldn=E2=80=99t?=
In-Reply-To: <jwvh7jx6jfn.fsf-monnier+emacs@HIDDEN>
Message-ID: <f2b9666c4af154b8671e@HIDDEN>
References: <fv2zojtus7b0tz.fsf@HIDDEN> <87r1jatd34.fsf@HIDDEN>
 <7dee3f423551aaf318cb@HIDDEN> <87im4kzlfm.fsf@HIDDEN>
 <1869622e16546eafd9df@HIDDEN> <jwvk0p04mbj.fsf-monnier+emacs@HIDDEN>
 <871rb6np5j.fsf@HIDDEN>
 <jwvczuqrm7s.fsf-monnier+emacs@HIDDEN> <87lf9cepqw.fsf@HIDDEN>
 <jwvsg3iig5h.fsf-monnier+emacs@HIDDEN>
 <jwvbla6if85.fsf-monnier+emacs@HIDDEN> <a87041afcb5f214d96a5@HIDDEN>
 <a87041afcb505462c0d5@HIDDEN> <jwv35vigog8.fsf-monnier+emacs@HIDDEN>
 <a87041afcb4761711a9a@HIDDEN> <jwv1rb1dhyu.fsf-monnier+emacs@HIDDEN>
 <f2b9666c4a7c09220e53@HIDDEN> <jwvmttp9mb4.fsf-monnier+emacs@HIDDEN>
 <f2b9666c4ad3eb906830@HIDDEN> <jwvwnst6n9z.fsf-monnier+emacs@HIDDEN>
 <f2b9666c4af5495f32cb@HIDDEN>
 <jwvh7jx6jfn.fsf-monnier+emacs@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset=us-ascii
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 45474
Cc: Dario Gjorgjevski <dario.gjorgjevski@HIDDEN>, 45474 <at> debbugs.gnu.org,
 Juri Linkov <juri@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)


>> Well, the fact that there were a few other pieces of code which do that 
>> was (at least as I understood it) part of the initial problem.  And the 
>> purpose of the discussion (at least as I understood it) was to solve 
>> the current problem without breaking these few other pieces of code.
>
> Indeed, and I think my patch should by and large leave them unaffected 
> (it neither magically fixes them nor breaks them).
>

Indeed, but... it doesn't help/incite them to move forward in the "right" 
direction, to finally have what has been on wishlist for quite a long 
time: to have buffer-local minibuffer-completion-* elements...

>> I admit that you lost me here.  What are these [SOMETHINGn]'s, and why 
>> are they happening?
>
> Because inevitably code can run in there, e.g. because the debugger gets 
> triggered in there or because the caller of `read-from-minibuffer` was 
> not careful to place the let-bindings of `minibuffer-completion-*` as 
> close as possible to `read-from-minibuffer`.
>

I see.  But when the let-bindings are in a macro the caller doesn't have 
to care with them, and they are indeed happening as close as possible to 
internal-read-from-minibuffer.  Unless they deliberately use 
internal-read-from-minibuffer and do some weird things, of course.

>
> [ Side note: you can't define `read-from-minibuffer` as a macro because 
> it is not compatible with the byte-code generated from code which called 
> `read-from-minibuffer` as a function.  So your patch would need to be 
> adjusted to keep `read-from-minibuffer` as a function. That opens up yet 
> more opportuninities for those [SOMETHINGn], such as advice placed on 
> `read-from-minibuffer`, ...  ]
>

I didn't know that ELC files had to be backward-compatible between major 
releases.  That being said, my preference would be to have the whole 
dancing happening at the C level (inside read_from_minibuffer and/or 
read_minibuf), which would solve that problem/these problems.

>>> You share the main downside of my proposal: `minibuffer-local-*` are 
>>> now only non-nil buffer-locally in the minibuffers.
>>>
>>> I mean it's good because it's what we want in the long term, but it's 
>>> bad because it's not backward compatible and there's probably some 
>>> code out there which will need to be adjusted to work with this.
>>
>> I have to admit again that you lost me here.
>
> No wonder: I wrote `minibuffer-local-*` when I meant 
> `minibuffer-completion-*`. Sorry 'bout that.
>

No worries ;-)  Now I see what you mean, and I do not see where you see a 
potential problem there: whether the minibuffer-completion-* elements 
become buffer-local depends on the minibuffer-local-completion variable. 
When it is nil (the default), they do not become buffer-local, and the 
behavior of read-from-minibuffer is the same as earlier.  This gives 
external package plenty of time to adapt their code to the future 
minibuffer-local-completion = t situation.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45474; Package emacs. Full text available.

Message received at 45474 <at> debbugs.gnu.org:


Received: (at 45474) by debbugs.gnu.org; 23 Apr 2021 17:37:40 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Apr 23 13:37:40 2021
Received: from localhost ([127.0.0.1]:38776 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lZzkK-0003Mm-CJ
	for submit <at> debbugs.gnu.org; Fri, 23 Apr 2021 13:37:40 -0400
Received: from eggs.gnu.org ([209.51.188.92]:38852)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1lZzkI-0003Mb-Pd
 for 45474 <at> debbugs.gnu.org; Fri, 23 Apr 2021 13:37:39 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:58958)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1lZzkB-0005Y7-Q1; Fri, 23 Apr 2021 13:37:31 -0400
Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3918
 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1lZzkB-0006nN-57; Fri, 23 Apr 2021 13:37:31 -0400
Date: Fri, 23 Apr 2021 20:37:23 +0300
Message-Id: <835z0coqb0.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <jwv35vh82dr.fsf-monnier+emacs@HIDDEN> (message from Stefan
 Monnier on Fri, 23 Apr 2021 11:18:48 -0400)
Subject: Re: bug#45474: Icomplete exhibiting in recursive minibuffer when it
 =?utf-8?Q?shouldn=E2=80=99t?=
References: <fv2zojtus7b0tz.fsf@HIDDEN> <3ed97a9c530093aca93d@HIDDEN>
 <7dee3f4235d331cab291@HIDDEN>
 <87r1jatd34.fsf@HIDDEN>
 <7dee3f423551aaf318cb@HIDDEN> <87im4kzlfm.fsf@HIDDEN>
 <1869622e16546eafd9df@HIDDEN>
 <jwvk0p04mbj.fsf-monnier+emacs@HIDDEN>
 <871rb6np5j.fsf@HIDDEN>
 <jwvczuqrm7s.fsf-monnier+emacs@HIDDEN>
 <87lf9cepqw.fsf@HIDDEN>
 <jwvsg3iig5h.fsf-monnier+emacs@HIDDEN>
 <jwvbla6if85.fsf-monnier+emacs@HIDDEN>
 <a87041afcb5f214d96a5@HIDDEN>
 <a87041afcb505462c0d5@HIDDEN>
 <jwv35vigog8.fsf-monnier+emacs@HIDDEN>
 <a87041afcb4761711a9a@HIDDEN>
 <jwv1rb1dhyu.fsf-monnier+emacs@HIDDEN> <83tunxo7pn.fsf@HIDDEN>
 <jwvsg3h9mlv.fsf-monnier+emacs@HIDDEN> <837dktnno1.fsf@HIDDEN>
 .fsf-monnier+emacs@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 45474
Cc: gregory@HIDDEN, juri@HIDDEN, dario.gjorgjevski@HIDDEN,
 45474 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Stefan Monnier <monnier@HIDDEN>
> Cc: gregory@HIDDEN,  dario.gjorgjevski@HIDDEN,
>   45474 <at> debbugs.gnu.org,  juri@HIDDEN
> Date: Fri, 23 Apr 2021 11:18:48 -0400
> 
> > It means I disagree that "all schemes using dynamic scoping to pass
> > the information are broken and messy".
> 
> ;-)
> 
> That's the part I understood, indeed.  There are two aspects which make
> it rather unclear to me:
> - First, from where I stand, what I stated is not really a matter of
>   opinion but a mere result of the underlying way the problem works.
>   There's a admittedly some amount of "degree" that can depend on some
>   of the details, which is why I said "similarly".
> - Second I don't know what it implies in terms of your opinion w.r.t the
>   various potential problems with:
>   - the current way of passing the information (just plain let-binding).
>   - the way proposed by Gregory (let-binding of minibuffer-complete-*
>     followed by let-binding to other-named vars followed by setq-local
>     of minibuffer-complete-*, where the dance is performed in
>     `read-from-minibuffer`).
>   - the way I suggested (minibuffer-with-setup-hook + setq-local, done
>     in `completing-read-default`).
>   It seems to suggest that you may not find them all "similarly
>   broken&messy", but even that is not sure.

Your original opinion sounded like a general objection to passing
information via let-binding of dynamic variables.  I wanted to voice
my disagreement with such a general POV.  I wasn't saying anything
about this particular use of dynamic binding.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45474; Package emacs. Full text available.

Message received at 45474 <at> debbugs.gnu.org:


Received: (at 45474) by debbugs.gnu.org; 23 Apr 2021 16:55:13 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Apr 23 12:55:12 2021
Received: from localhost ([127.0.0.1]:38698 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lZz5E-0002Fe-KL
	for submit <at> debbugs.gnu.org; Fri, 23 Apr 2021 12:55:12 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:16598)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1lZz5D-0002FO-F9
 for 45474 <at> debbugs.gnu.org; Fri, 23 Apr 2021 12:55:11 -0400
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
 by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 927534406D7;
 Fri, 23 Apr 2021 12:55:05 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 4143E440087;
 Fri, 23 Apr 2021 12:55:03 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1619196903;
 bh=pmpsq8hReFvBv9ri95zUaHvVoMitlYV0BeY6QJ6Rgfs=;
 h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
 b=RseEhD4CFFj6uuDTfFtUUxXrwgIK/4g4YknTA6ZJKOQteVmP3NwvbtW3O3xYVOrHq
 gYGkgYQuVIcJxrek1Aiwt6L0uv4x0/Y68vBao9Z9rqSnX27cUFLF5zWglI/glIInR7
 FTqauThpXa/DkWzn6uJjwssd6vJggghoPFmawVsZT9tAPej0NxKMdutoaXT/Z/kj8A
 t48yc8ALyVsGgUsKETMzcNfmHo19lQcloW/1md+MDZjie+nz6I92VUel5eVLEKjJ4d
 oGaHsp1J5giah+dezjy87D0rv3/TTMhsUA6LcI1ltI4isP3mh57FA5oXPjxdHwyzLi
 WzoFbbzwX62Rg==
Received: from alfajor (104-222-126-84.cpe.teksavvy.com [104.222.126.84])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id EC0101201E6;
 Fri, 23 Apr 2021 12:55:02 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Gregory Heytings <gregory@HIDDEN>
Subject: Re: bug#45474: Icomplete exhibiting in recursive minibuffer when it
 =?utf-8?Q?shouldn=E2=80=99t?=
Message-ID: <jwvh7jx6jfn.fsf-monnier+emacs@HIDDEN>
References: <fv2zojtus7b0tz.fsf@HIDDEN> <87r1jatd34.fsf@HIDDEN>
 <7dee3f423551aaf318cb@HIDDEN> <87im4kzlfm.fsf@HIDDEN>
 <1869622e16546eafd9df@HIDDEN>
 <jwvk0p04mbj.fsf-monnier+emacs@HIDDEN>
 <871rb6np5j.fsf@HIDDEN>
 <jwvczuqrm7s.fsf-monnier+emacs@HIDDEN>
 <87lf9cepqw.fsf@HIDDEN>
 <jwvsg3iig5h.fsf-monnier+emacs@HIDDEN>
 <jwvbla6if85.fsf-monnier+emacs@HIDDEN>
 <a87041afcb5f214d96a5@HIDDEN>
 <a87041afcb505462c0d5@HIDDEN>
 <jwv35vigog8.fsf-monnier+emacs@HIDDEN>
 <a87041afcb4761711a9a@HIDDEN>
 <jwv1rb1dhyu.fsf-monnier+emacs@HIDDEN>
 <f2b9666c4a7c09220e53@HIDDEN>
 <jwvmttp9mb4.fsf-monnier+emacs@HIDDEN>
 <f2b9666c4ad3eb906830@HIDDEN>
 <jwvwnst6n9z.fsf-monnier+emacs@HIDDEN>
 <f2b9666c4af5495f32cb@HIDDEN>
Date: Fri, 23 Apr 2021 12:55:02 -0400
In-Reply-To: <f2b9666c4af5495f32cb@HIDDEN> (Gregory Heytings's message
 of "Fri, 23 Apr 2021 15:58:51 +0000")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.095 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 45474
Cc: Dario Gjorgjevski <dario.gjorgjevski@HIDDEN>, 45474 <at> debbugs.gnu.org,
 Juri Linkov <juri@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Well, the fact that there were a few other pieces of code which do that was
> (at least as I understood it) part of the initial problem.  And the purpose
> of the discussion (at least as I understood it) was to solve the current
> problem without breaking these few other pieces of code.

Indeed, and I think my patch should by and large leave them unaffected
(it neither magically fixes them nor breaks them).

>>> If not, it means that your patch will fix the problem for
>>> completing-read-default, but not for other completion backends, who will
>>> have to resort on a similar trick to get the same effect.
>>
>> I think they'd need to make similar changes to fix the problem under
>> discussion in this longish thread, but they can keep using their old way
>> of working and the consequence will just be that they will keep suffering
>> from the old problem.
> With my patch all they have to do is to add (minibuffer-local-completion t)
> before calling read-from-minibuffer.

I think whichever approach we choose, the fix is pretty simple.
IMO the only real gain we can try and aim for is to minimize the need for
change at all.

>>> Not with the patch I'm proposing.  What it does is the following (in
>>> abbreviated form):
>>>
>>> (let ((minibuffer-local-* minibuffer-completion-*))
>>>    (let ((minibuffer-completion-* nil))
>>>       (internal-read-from-minibuffer ...)))
>>
>> Not quite.  The actual code is more like:
>>
>>    (let ((minibuffer-local-* minibuffer-completion-*))
>>       [SOMETHING1]
>>       (let ((minibuffer-completion-* nil))
>>          (internal-read-from-minibuffer ...))
>>       [SOMETHING2])
>>
>> and those two [SOMETHINGn] still leak.
>
> I admit that you lost me here.  What are these [SOMETHINGn]'s, and why are
> they happening?

Because inevitably code can run in there, e.g. because the debugger gets
triggered in there or because the caller of `read-from-minibuffer` was not
careful to place the let-bindings of `minibuffer-completion-*` as close
as possible to `read-from-minibuffer`.

[ Side note: you can't define `read-from-minibuffer` as a macro because
  it is not compatible with the byte-code generated from code which
  called `read-from-minibuffer` as a function.  So your patch would
  need to be adjusted to keep `read-from-minibuffer` as a function.
  That opens up yet more opportuninities for those [SOMETHINGn], such
  as advice placed on `read-from-minibuffer`, ...  ]

BTW, these corner case problems are the same kind of corner case
problems which plague `minibuffer-with-setup-hook` as well, of course.

>> You share the main downside of my proposal: `minibuffer-local-*` are now
>> only non-nil buffer-locally in the minibuffers.
>>
>> I mean it's good because it's what we want in the long term, but it's bad
>> because it's not backward compatible and there's probably some code out
>> there which will need to be adjusted to work with this.
>
> I have to admit again that you lost me here.

No wonder: I wrote `minibuffer-local-*` when I meant `minibuffer-completion-*`.
Sorry 'bout that.


        Stefan





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45474; Package emacs. Full text available.

Message received at 45474 <at> debbugs.gnu.org:


Received: (at 45474) by debbugs.gnu.org; 23 Apr 2021 16:38:46 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Apr 23 12:38:46 2021
Received: from localhost ([127.0.0.1]:38682 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lZypK-0001rY-5i
	for submit <at> debbugs.gnu.org; Fri, 23 Apr 2021 12:38:46 -0400
Received: from relay1-d.mail.gandi.net ([217.70.183.193]:10791)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <juri@HIDDEN>) id 1lZypI-0001r7-1J
 for 45474 <at> debbugs.gnu.org; Fri, 23 Apr 2021 12:38:44 -0400
X-Originating-IP: 91.129.102.166
Received: from mail.gandi.net (m91-129-102-166.cust.tele2.ee [91.129.102.166])
 (Authenticated sender: juri@HIDDEN)
 by relay1-d.mail.gandi.net (Postfix) with ESMTPSA id F0C58240004;
 Fri, 23 Apr 2021 16:38:35 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: Gregory Heytings <gregory@HIDDEN>
Subject: Re: bug#45474: Icomplete exhibiting in recursive minibuffer when it
 =?utf-8?Q?shouldn=E2=80=99t?=
Organization: LINKOV.NET
References: <fv2zojtus7b0tz.fsf@HIDDEN> <87r1jatd34.fsf@HIDDEN>
 <7dee3f423551aaf318cb@HIDDEN> <87im4kzlfm.fsf@HIDDEN>
 <1869622e16546eafd9df@HIDDEN>
 <jwvk0p04mbj.fsf-monnier+emacs@HIDDEN>
 <871rb6np5j.fsf@HIDDEN>
 <jwvczuqrm7s.fsf-monnier+emacs@HIDDEN>
 <87lf9cepqw.fsf@HIDDEN>
 <jwvsg3iig5h.fsf-monnier+emacs@HIDDEN>
 <jwvbla6if85.fsf-monnier+emacs@HIDDEN>
 <a87041afcb5f214d96a5@HIDDEN>
 <a87041afcb505462c0d5@HIDDEN>
 <jwv35vigog8.fsf-monnier+emacs@HIDDEN>
 <a87041afcb4761711a9a@HIDDEN>
 <jwv1rb1dhyu.fsf-monnier+emacs@HIDDEN>
 <f2b9666c4a7c09220e53@HIDDEN>
 <jwvmttp9mb4.fsf-monnier+emacs@HIDDEN>
 <f2b9666c4ad3eb906830@HIDDEN>
 <jwvwnst6n9z.fsf-monnier+emacs@HIDDEN>
 <f2b9666c4af5495f32cb@HIDDEN>
Date: Fri, 23 Apr 2021 19:36:16 +0300
In-Reply-To: <f2b9666c4af5495f32cb@HIDDEN> (Gregory Heytings's message
 of "Fri, 23 Apr 2021 15:58:51 +0000")
Message-ID: <87bla5gdtj.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 45474
Cc: Dario Gjorgjevski <dario.gjorgjevski@HIDDEN>,
 Stefan Monnier <monnier@HIDDEN>, 45474 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

>>> If not, it means that your patch will fix the problem for
>>> completing-read-default, but not for other completion backends, who will
>>> have to resort on a similar trick to get the same effect.
>>
>> I think they'd need to make similar changes to fix the problem under
>> discussion in this longish thread, but they can keep using their old way
>> of working and the consequence will just be that they will keep suffering
>> from the old problem.
>
> With my patch all they have to do is to add (minibuffer-local-completion t)
> before calling read-from-minibuffer.

Since other completion backends need to add (minibuffer-local-completion t)
anyway, the safest and most backward-compatible solution is to set
this new variable buffer-local in completing-read-default with

          (minibuffer-with-setup-hook
              (lambda ()
                (setq-local minibuffer-local-completion t))
            (read-from-minibuffer prompt initial-input keymap
                                  nil hist def inherit-input-method))))

Then modes like icomplete interested in knowing whether the minibuffer
was created for completions, can check for the buffer-local value
of minibuffer-local-completion.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45474; Package emacs. Full text available.

Message received at 45474 <at> debbugs.gnu.org:


Received: (at 45474) by debbugs.gnu.org; 23 Apr 2021 15:58:55 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Apr 23 11:58:55 2021
Received: from localhost ([127.0.0.1]:38639 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lZyCl-0000qL-7t
	for submit <at> debbugs.gnu.org; Fri, 23 Apr 2021 11:58:55 -0400
Received: from heytings.org ([95.142.160.155]:50314)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <gregory@HIDDEN>) id 1lZyCj-0000qD-Jk
 for 45474 <at> debbugs.gnu.org; Fri, 23 Apr 2021 11:58:54 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org;
 s=20210101; t=1619193532;
 bh=cfrdT3AzX8PSHJvTBv8oERmKOmITxiRrlQ0rHGhDdgU=;
 h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From;
 b=KcIH5IqycflRR0dT8EPsl5ANxMF0iLcp8YtWbmA9hNruarurZPMC3cO2z+9CsfT5t
 OZ1Mf8ZA4mTreEnfFCKAlZu88x086tRfOMa8rAxuMPYX+VdAiBuSLCJRxnbgdx3gAh
 /tE4jvg12DXRppTTN8C3eFdeXZISEPkIgWHwybQjapxmSEGReg76Zxhce7nU8B8fY7
 k/tHkfVcaTuMU97euSDuDPRTG55W77Fnhn+qG3zJtvtL9gRLuz0Ruk2vIHjbGiFu6F
 TJLsPWuHgORQSCsqVqY6XDCOU09WQzld8zg4FVEf8soHYAKk+PmIkJLgG3xat+Ztl/
 IuZ9gzSut38UA==
Date: Fri, 23 Apr 2021 15:58:51 +0000
From: Gregory Heytings <gregory@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
Subject: =?UTF-8?Q?Re=3A_bug#45474=3A_Icomplete_exhibiting_in_recursive?=
 =?UTF-8?Q?_minibuffer_when_it_shouldn=E2=80=99t?=
In-Reply-To: <jwvwnst6n9z.fsf-monnier+emacs@HIDDEN>
Message-ID: <f2b9666c4af5495f32cb@HIDDEN>
References: <fv2zojtus7b0tz.fsf@HIDDEN> <3ed97a9c530093aca93d@HIDDEN>
 <7dee3f4235d331cab291@HIDDEN> <87r1jatd34.fsf@HIDDEN>
 <7dee3f423551aaf318cb@HIDDEN> <87im4kzlfm.fsf@HIDDEN>
 <1869622e16546eafd9df@HIDDEN>
 <jwvk0p04mbj.fsf-monnier+emacs@HIDDEN> <871rb6np5j.fsf@HIDDEN>
 <jwvczuqrm7s.fsf-monnier+emacs@HIDDEN> <87lf9cepqw.fsf@HIDDEN>
 <jwvsg3iig5h.fsf-monnier+emacs@HIDDEN>
 <jwvbla6if85.fsf-monnier+emacs@HIDDEN> <a87041afcb5f214d96a5@HIDDEN>
 <a87041afcb505462c0d5@HIDDEN> <jwv35vigog8.fsf-monnier+emacs@HIDDEN>
 <a87041afcb4761711a9a@HIDDEN> <jwv1rb1dhyu.fsf-monnier+emacs@HIDDEN>
 <f2b9666c4a7c09220e53@HIDDEN> <jwvmttp9mb4.fsf-monnier+emacs@HIDDEN>
 <f2b9666c4ad3eb906830@HIDDEN>
 <jwvwnst6n9z.fsf-monnier+emacs@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset=us-ascii
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 45474
Cc: Dario Gjorgjevski <dario.gjorgjevski@HIDDEN>, 45474 <at> debbugs.gnu.org,
 Juri Linkov <juri@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)


Thanks for your detailed comments.

>> By 'completing-read-default' _and_ by other completion backends that 
>> set minibuffer-completion-* elements and call read-from-minibuffer. 
>> Or am I misunderstanding something?
>
> AFAICT there are very few other pieces of code which let-bind (or set) 
> minibuffer-completion-*.  And my suggested patch should hopefully not 
> affect them too significantly.  Also I don't think we can fix this 
> problem without introducing corner-case incompatibilities and/or extra 
> code/changes in other frontends or backends.
>

Well, the fact that there were a few other pieces of code which do that 
was (at least as I understood it) part of the initial problem.  And the 
purpose of the discussion (at least as I understood it) was to solve the 
current problem without breaking these few other pieces of code.

>> If not, it means that your patch will fix the problem for 
>> completing-read-default, but not for other completion backends, who 
>> will have to resort on a similar trick to get the same effect.
>
> I think they'd need to make similar changes to fix the problem under 
> discussion in this longish thread, but they can keep using their old way 
> of working and the consequence will just be that they will keep 
> suffering from the old problem.
>

With my patch all they have to do is to add (minibuffer-local-completion 
t) before calling read-from-minibuffer.

>> Not with the patch I'm proposing.  What it does is the following (in 
>> abbreviated form):
>>
>> (let ((minibuffer-local-* minibuffer-completion-*))
>>    (let ((minibuffer-completion-* nil))
>>       (internal-read-from-minibuffer ...)))
>
> Not quite.  The actual code is more like:
>
>    (let ((minibuffer-local-* minibuffer-completion-*))
>       [SOMETHING1]
>       (let ((minibuffer-completion-* nil))
>          (internal-read-from-minibuffer ...))
>       [SOMETHING2])
>
> and those two [SOMETHINGn] still leak.
>

I admit that you lost me here.  What are these [SOMETHINGn]'s, and why are 
they happening?  Wasn't the point to not leak the minibuffer-completion-* 
variables?

>
> [ Another problem is that this approach breaks when you have 
> simultaneous active minibuffers, and the inner minibuffer is triggered 
> from the outer one (e.g. `C-x C-f` following by `C-h o`) since the 
> let-bindings above will (when run for the `C-h o`) temporarily override 
> the completion information of the outer minibuffer. This is not too 
> serious in the sense that it's no worse than what we have now, tho.  ]
>

I won't comment on this, because I'm deeply saddened to see this 
happening.  Emacs has had a nice Lisp-like stack of minibuffers forever, 
what the purpose of this new thing is is beyond me.

>
> You share the main downside of my proposal: `minibuffer-local-*` are now 
> only non-nil buffer-locally in the minibuffers.
>
> I mean it's good because it's what we want in the long term, but it's 
> bad because it's not backward compatible and there's probably some code 
> out there which will need to be adjusted to work with this.
>

I have to admit again that you lost me here.  What do you mean?  With my 
patch, inside the minibuffer, the minibuffer-local-* variables aren't used 
anymore, the usual minibuffer-completion-* variables are used, and they 
are buffer-local, so the sole and only thing that a piece of code wishing 
to use the new semantics needs to do is to let-bind 
(minibuffer-local-completion t) around the read-from-minibuffer call.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45474; Package emacs. Full text available.

Message received at 45474 <at> debbugs.gnu.org:


Received: (at 45474) by debbugs.gnu.org; 23 Apr 2021 15:53:23 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Apr 23 11:53:23 2021
Received: from localhost ([127.0.0.1]:38632 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lZy7P-0000ht-6h
	for submit <at> debbugs.gnu.org; Fri, 23 Apr 2021 11:53:23 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:49805)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1lZy7N-0000hh-OH
 for 45474 <at> debbugs.gnu.org; Fri, 23 Apr 2021 11:53:22 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 171D98088B;
 Fri, 23 Apr 2021 11:53:16 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id A6AA2801AB;
 Fri, 23 Apr 2021 11:53:14 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1619193194;
 bh=wBzgpRHwE6wHjq4wP6AnAZjf8tMqDrGnj/ur5zXh5C8=;
 h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
 b=OQQ/bFSUf71yxp9Y5UzCAhEJoJj8563R4AWzMc8j1xkbKX58OwbNkSO/oEwjCupMK
 Gy6nEjoSvIKXdA0tPsjL/PmR52Fm/PZ0QDbEi1rcbtuoOCg9ZM48J+W8KmOGxWAaPK
 SQugSp6J+04xFm26odHXtKXSnBPRMNfey3l58MXJczfERdN/aHa0FENlOFBlORcFNw
 DC5QHLQ87fKgSiEV3MbadvgTqMbm7hXsI1aPmdjUc2udMZYlIzCcjum9GX6+CnOC3k
 tqda5fmyvPQO20Ql/HBIk/0QZU0cGy7nm1QyNTGyZDxNlhEpDwtGyrTRi1JOfUc5Ju
 XGj6gh4p8HEWQ==
Received: from alfajor (104-222-126-84.cpe.teksavvy.com [104.222.126.84])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 7398E12038D;
 Fri, 23 Apr 2021 11:53:14 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Juri Linkov <juri@HIDDEN>
Subject: Re: bug#45474: Icomplete exhibiting in recursive minibuffer when it
 =?utf-8?Q?shouldn=E2=80=99t?=
Message-ID: <jwvr1j16m1s.fsf-monnier+emacs@HIDDEN>
References: <fv2zojtus7b0tz.fsf@HIDDEN> <3ed97a9c53e0a5d4fef8@HIDDEN>
 <87fszrz21d.fsf@HIDDEN>
 <3ed97a9c530093aca93d@HIDDEN>
 <7dee3f4235d331cab291@HIDDEN> <87r1jatd34.fsf@HIDDEN>
 <7dee3f423551aaf318cb@HIDDEN> <87im4kzlfm.fsf@HIDDEN>
 <1869622e16546eafd9df@HIDDEN>
 <jwvk0p04mbj.fsf-monnier+emacs@HIDDEN>
 <871rb6np5j.fsf@HIDDEN>
 <jwvczuqrm7s.fsf-monnier+emacs@HIDDEN>
 <87lf9cepqw.fsf@HIDDEN>
 <jwvsg3iig5h.fsf-monnier+emacs@HIDDEN>
 <jwvbla6if85.fsf-monnier+emacs@HIDDEN>
 <87k0oukn3n.fsf@HIDDEN>
Date: Fri, 23 Apr 2021 11:53:13 -0400
In-Reply-To: <87k0oukn3n.fsf@HIDDEN> (Juri Linkov's message of "Fri, 
 23 Apr 2021 00:57:56 +0300")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.059 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 45474
Cc: Gregory Heytings <gregory@HIDDEN>,
 Dario Gjorgjevski <dario.gjorgjevski@HIDDEN>, 45474 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

>> I'm more and more thinking that we should really bite the bullet and go
>> for a "really buffer-local" setup, such as in the patch below.
>> I'd be surprised if it doesn't introduce backward incompatibilities, but
>> at least it's "The Right Thing" to do.
> I've tested your new patch with tests that Gregory posted
> in an earlier message that cover all cases of nested
> completion and non-completion minibuffers:

AFAICT my proposed patch should work fine with the builtin UI and with
icomplete, yes.  I expect ido-ubiquitous should also work just fine.

The only significant source of incompatibility I can foresee is for code
which uses `minibuffer-completion-*` from code running outside of the
minibuffer (such as in a buffer like *Completion*).

There's another source of incompatibility for functions that currently
operate like `completion-read-default` (i.e. let-bind
`minibuffer-completion-*` and then use that setting in another buffer,
such as a new minibuffer): these may fail to work when used from within
a completing minibuffer.


        Stefan





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45474; Package emacs. Full text available.

Message received at 45474 <at> debbugs.gnu.org:


Received: (at 45474) by debbugs.gnu.org; 23 Apr 2021 15:35:56 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Apr 23 11:35:56 2021
Received: from localhost ([127.0.0.1]:38607 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lZxqW-0000Fj-HY
	for submit <at> debbugs.gnu.org; Fri, 23 Apr 2021 11:35:56 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:63122)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1lZxqU-0000FU-0p
 for 45474 <at> debbugs.gnu.org; Fri, 23 Apr 2021 11:35:54 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 2C9D3100317;
 Fri, 23 Apr 2021 11:35:48 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 0A23D10021B;
 Fri, 23 Apr 2021 11:35:42 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1619192142;
 bh=SwxDuD217CJXz9jU8Bckyy8OMUjK5tr/EW9kbl5kfII=;
 h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
 b=HsAUZKuBfZuVfmWv/13s0dpaxHMMDrIugECKoqhWvqZndbXhdS79QMswCbnl+QhLj
 ICo1HIeyCtbaKBPKF5MlWy7U/8bd4h80F1UVodCZE/iTxw22slSJy1i84obrrQYVDt
 ypsVwk17WB8xz04LC2ufrlaZOZdWWkIAl88BWse4UWrCl8ouJa22P4GWBGQixnhuFp
 CzOLO80W5DibkJPyW5U8CYGWeKDqaXLP+jCdVatzAiyhTPYpvg/msGaHMVePH0c7oc
 Uifj2D2e/fwhTgD9yik2KBwrk+ttS5AjBDp6cgfVGY3YJ5NkdIJAdWTL0XPVa8/vlW
 TM/FnVXRDwIwQ==
Received: from alfajor (104-222-126-84.cpe.teksavvy.com [104.222.126.84])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id CA2F71202C2;
 Fri, 23 Apr 2021 11:35:41 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Gregory Heytings <gregory@HIDDEN>
Subject: Re: bug#45474: Icomplete exhibiting in recursive minibuffer when it
 =?utf-8?Q?shouldn=E2=80=99t?=
Message-ID: <jwvwnst6n9z.fsf-monnier+emacs@HIDDEN>
References: <fv2zojtus7b0tz.fsf@HIDDEN> <3ed97a9c530093aca93d@HIDDEN>
 <7dee3f4235d331cab291@HIDDEN>
 <87r1jatd34.fsf@HIDDEN>
 <7dee3f423551aaf318cb@HIDDEN> <87im4kzlfm.fsf@HIDDEN>
 <1869622e16546eafd9df@HIDDEN>
 <jwvk0p04mbj.fsf-monnier+emacs@HIDDEN>
 <871rb6np5j.fsf@HIDDEN>
 <jwvczuqrm7s.fsf-monnier+emacs@HIDDEN>
 <87lf9cepqw.fsf@HIDDEN>
 <jwvsg3iig5h.fsf-monnier+emacs@HIDDEN>
 <jwvbla6if85.fsf-monnier+emacs@HIDDEN>
 <a87041afcb5f214d96a5@HIDDEN>
 <a87041afcb505462c0d5@HIDDEN>
 <jwv35vigog8.fsf-monnier+emacs@HIDDEN>
 <a87041afcb4761711a9a@HIDDEN>
 <jwv1rb1dhyu.fsf-monnier+emacs@HIDDEN>
 <f2b9666c4a7c09220e53@HIDDEN>
 <jwvmttp9mb4.fsf-monnier+emacs@HIDDEN>
 <f2b9666c4ad3eb906830@HIDDEN>
Date: Fri, 23 Apr 2021 11:35:40 -0400
In-Reply-To: <f2b9666c4ad3eb906830@HIDDEN> (Gregory Heytings's message
 of "Fri, 23 Apr 2021 13:45:47 +0000")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.033 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 45474
Cc: Dario Gjorgjevski <dario.gjorgjevski@HIDDEN>, 45474 <at> debbugs.gnu.org,
 Juri Linkov <juri@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

>>> It seems to me that my proposal is better, and here's why.  The right
>>> thing to do in this case is not to install a local fix in
>>> completing-read-default, because completing-read-default is not where the
>>> root cause of the current problem lies.
>>
>> Hmm... that's odd: the problem has to do with values of
>> `minibuffer-completion-*` appearing where they shouldn't, and those values
>> are set by `completing-read-default`, so I think it's clearly the culprit.
>
> By 'completing-read-default' _and_ by other completion backends that set
> minibuffer-completion-* elements and call read-from-minibuffer.  Or am
> I misunderstanding something?

AFAICT there are very few other pieces of code which let-bind (or set)
minibuffer-completion-*.  And my suggested patch should hopefully not
affect them too significantly.  Also I don't think we can fix this
problem without introducing corner-case incompatibilities and/or extra
code/changes in other frontends or backends.

> If not, it means that your patch will fix the problem for
> completing-read-default, but not for other completion backends, who will
> have to resort on a similar trick to get the same effect.

I think they'd need to make similar changes to fix the problem under
discussion in this longish thread, but they can keep using their old way
of working and the consequence will just be that they will keep
suffering from the old problem.

>> The core problem is the fact that dynamic scoping leaks: the parameters
>> passed to `read-from-minibuffer` via dynamic scoping and up being passed
>> to all other uses of `read-from-minibuffer` which happen to take place
>> within the same dynamic extent.
> Not with the patch I'm proposing.  What it does is the following (in
> abbreviated form):
>
> (let ((minibuffer-local-* minibuffer-completion-*))
>    (let ((minibuffer-completion-* nil))
>       (internal-read-from-minibuffer ...)))

Not quite.  The actual code is more like:

    (let ((minibuffer-local-* minibuffer-completion-*))
       [SOMETHING1]
       (let ((minibuffer-completion-* nil))
          (internal-read-from-minibuffer ...))
       [SOMETHING2])

and those two [SOMETHINGn] still leak.

[ Another problem is that this approach breaks when you have
  simultaneous active minibuffers, and the inner minibuffer is triggered
  from the outer one (e.g. `C-x C-f` following by `C-h o`) since the
  let-bindings above will (when run for the `C-h o`) temporarily
  override the completion information of the outer minibuffer.
  This is not too serious in the sense that it's no worse than what we
  have now, tho.  ]

> Line 1 saves the parameters in temporary variables, and line 2 resets the
> values of the parameters to nil, which means that they will not be visible
> anymore to all other uses of read-from-minibuffer within the same dynamic
> extent.  Isn't that a nice trick?
>
> So you get all you want at once:
>
> - receiving the arguments from the environment (thereby avoiding to add new
>  explicit parameters)
>
> - buffer-local values of the arguments on demand (thereby getting better
>    semantics for callers that want it, in particular
>   completing-read-default)
>
> - be backward compatible the current semantics of read-from-minibufer
>    (thereby avoiding to break compatibility for callers that did not adapt
>    to the the new semantics)

You share the main downside of my proposal:
`minibuffer-local-*` are now only non-nil buffer-locally in
the minibuffers.

I mean it's good because it's what we want in the long term, but it's
bad because it's not backward compatible and there's probably some code
out there which will need to be adjusted to work with this.


        Stefan





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45474; Package emacs. Full text available.

Message received at 45474 <at> debbugs.gnu.org:


Received: (at 45474) by debbugs.gnu.org; 23 Apr 2021 15:19:02 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Apr 23 11:19:02 2021
Received: from localhost ([127.0.0.1]:38529 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lZxa9-0008Ek-OB
	for submit <at> debbugs.gnu.org; Fri, 23 Apr 2021 11:19:02 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:62230)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1lZxa4-0008EF-HE
 for 45474 <at> debbugs.gnu.org; Fri, 23 Apr 2021 11:19:00 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 20144801AB;
 Fri, 23 Apr 2021 11:18:51 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 845078088B;
 Fri, 23 Apr 2021 11:18:49 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1619191129;
 bh=k1Apy1bqVmVDktxeirfc0ZhObha2aSs09gwntjZzD0E=;
 h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
 b=bPODPLupIkCdi2kKVKvVMXhnq3d+fjfo3W45QASavYR2583rn8bMNdKI7lUragI04
 gh0PkSSpTPBsve4GCB5hYJoYEHWou5wHihMMAtWTPh9S0n6uYJH642rBFOWpE/vbmg
 9ROcrKj0RnrkWqNEWM4OwLG85HiKcwDm0Fc5jyWFgAzyxzDc4pxyR47Zm7V2fZ31Pe
 Tj4KKrOKlx+PrkfnNWZEKVG5MfPHC4kooPgifPdBXbncsl5PpWpr+xsAUL3pCfh4BN
 1c8KmEC8PkFc/3B2QoCYeI6ZcpL7OUjx3JDqRi+Sx5SDZXoE9y/KrZFrprWpZ0uFdo
 4De+g4uS10epw==
Received: from alfajor (104-222-126-84.cpe.teksavvy.com [104.222.126.84])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 47ED2120249;
 Fri, 23 Apr 2021 11:18:49 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#45474: Icomplete exhibiting in recursive minibuffer when it
 =?utf-8?Q?shouldn=E2=80=99t?=
Message-ID: <jwv35vh82dr.fsf-monnier+emacs@HIDDEN>
References: <fv2zojtus7b0tz.fsf@HIDDEN> <3ed97a9c530093aca93d@HIDDEN>
 <7dee3f4235d331cab291@HIDDEN>
 <87r1jatd34.fsf@HIDDEN>
 <7dee3f423551aaf318cb@HIDDEN> <87im4kzlfm.fsf@HIDDEN>
 <1869622e16546eafd9df@HIDDEN>
 <jwvk0p04mbj.fsf-monnier+emacs@HIDDEN>
 <871rb6np5j.fsf@HIDDEN>
 <jwvczuqrm7s.fsf-monnier+emacs@HIDDEN>
 <87lf9cepqw.fsf@HIDDEN>
 <jwvsg3iig5h.fsf-monnier+emacs@HIDDEN>
 <jwvbla6if85.fsf-monnier+emacs@HIDDEN>
 <a87041afcb5f214d96a5@HIDDEN>
 <a87041afcb505462c0d5@HIDDEN>
 <jwv35vigog8.fsf-monnier+emacs@HIDDEN>
 <a87041afcb4761711a9a@HIDDEN>
 <jwv1rb1dhyu.fsf-monnier+emacs@HIDDEN> <83tunxo7pn.fsf@HIDDEN>
 <jwvsg3h9mlv.fsf-monnier+emacs@HIDDEN> <837dktnno1.fsf@HIDDEN>
Date: Fri, 23 Apr 2021 11:18:48 -0400
In-Reply-To: <837dktnno1.fsf@HIDDEN> (Eli Zaretskii's message of "Fri, 23 Apr
 2021 16:19:42 +0300")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.060 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 45474
Cc: gregory@HIDDEN, juri@HIDDEN, dario.gjorgjevski@HIDDEN,
 45474 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

>> >> > Indeed, but you said that 'minibuffer-with-setup-hook' is "fundamentally
>> >> > broken and messy"...
>> >> All schemes using dynamic scoping to pass the information are similarly
>> >> broken&messy
>> > I don't agree.
>> I don't know what that means, here.
> It means I disagree that "all schemes using dynamic scoping to pass
> the information are broken and messy".

;-)

That's the part I understood, indeed.  There are two aspects which make
it rather unclear to me:
- First, from where I stand, what I stated is not really a matter of
  opinion but a mere result of the underlying way the problem works.
  There's a admittedly some amount of "degree" that can depend on some
  of the details, which is why I said "similarly".
- Second I don't know what it implies in terms of your opinion w.r.t the
  various potential problems with:
  - the current way of passing the information (just plain let-binding).
  - the way proposed by Gregory (let-binding of minibuffer-complete-*
    followed by let-binding to other-named vars followed by setq-local
    of minibuffer-complete-*, where the dance is performed in
    `read-from-minibuffer`).
  - the way I suggested (minibuffer-with-setup-hook + setq-local, done
    in `completing-read-default`).
  It seems to suggest that you may not find them all "similarly
  broken&messy", but even that is not sure.


        Stefan





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45474; Package emacs. Full text available.

Message received at 45474 <at> debbugs.gnu.org:


Received: (at 45474) by debbugs.gnu.org; 23 Apr 2021 13:45:51 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Apr 23 09:45:51 2021
Received: from localhost ([127.0.0.1]:36456 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lZw7z-0005Qz-He
	for submit <at> debbugs.gnu.org; Fri, 23 Apr 2021 09:45:51 -0400
Received: from heytings.org ([95.142.160.155]:50186)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <gregory@HIDDEN>) id 1lZw7w-0005Qo-PH
 for 45474 <at> debbugs.gnu.org; Fri, 23 Apr 2021 09:45:49 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org;
 s=20210101; t=1619185547;
 bh=VslNeW9gQ1WQxYUl8PJKD59aOonOCuTx1rMPz5NX+YY=;
 h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From;
 b=tDuC1UoaaWQy3kOeYnA0Fsfo2f/mInoBMyxB9k0bZgttuG3d6/S51e2udw3gX5WiO
 jqKLcx1wz+TvMRrP4cp8nmemNT0x4w56yAFhiEMKcQPs4ZvWosuLkx45rM5be79wki
 wsg+xowPmstFAuAVX5O7TbFl0yHjnzxyhgP9M58PCx/X0X5p2/e3A6kSw63ZkZsCDU
 9opYXfpOalKpgx3vV81Q/1fMZwASUax3yCPNZwwlwUPbgkkXAShCRIgVLIOEzvLk0R
 vNTubdJGYQ7ZhcRPzn5ReWK2B6N4ZPVQzsxD8GYOMNFXVhAvxL32BMLxkdR9pyutbu
 a5dicQFVFMpoQ==
Date: Fri, 23 Apr 2021 13:45:47 +0000
From: Gregory Heytings <gregory@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
Subject: =?UTF-8?Q?Re=3A_bug#45474=3A_Icomplete_exhibiting_in_recursive?=
 =?UTF-8?Q?_minibuffer_when_it_shouldn=E2=80=99t?=
In-Reply-To: <jwvmttp9mb4.fsf-monnier+emacs@HIDDEN>
Message-ID: <f2b9666c4ad3eb906830@HIDDEN>
References: <fv2zojtus7b0tz.fsf@HIDDEN> <3ed97a9c53e0a5d4fef8@HIDDEN>
 <87fszrz21d.fsf@HIDDEN> <3ed97a9c530093aca93d@HIDDEN>
 <7dee3f4235d331cab291@HIDDEN> <87r1jatd34.fsf@HIDDEN>
 <7dee3f423551aaf318cb@HIDDEN>
 <87im4kzlfm.fsf@HIDDEN> <1869622e16546eafd9df@HIDDEN>
 <jwvk0p04mbj.fsf-monnier+emacs@HIDDEN> <871rb6np5j.fsf@HIDDEN>
 <jwvczuqrm7s.fsf-monnier+emacs@HIDDEN> <87lf9cepqw.fsf@HIDDEN>
 <jwvsg3iig5h.fsf-monnier+emacs@HIDDEN>
 <jwvbla6if85.fsf-monnier+emacs@HIDDEN> <a87041afcb5f214d96a5@HIDDEN>
 <a87041afcb505462c0d5@HIDDEN> <jwv35vigog8.fsf-monnier+emacs@HIDDEN>
 <a87041afcb4761711a9a@HIDDEN> <jwv1rb1dhyu.fsf-monnier+emacs@HIDDEN>
 <f2b9666c4a7c09220e53@HIDDEN>
 <jwvmttp9mb4.fsf-monnier+emacs@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 45474
Cc: Dario Gjorgjevski <dario.gjorgjevski@HIDDEN>, 45474 <at> debbugs.gnu.org,
 Juri Linkov <juri@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)


>> It seems to me that my proposal is better, and here's why.  The right 
>> thing to do in this case is not to install a local fix in 
>> completing-read-default, because completing-read-default is not where 
>> the root cause of the current problem lies.
>
> Hmm... that's odd: the problem has to do with values of 
> `minibuffer-completion-*` appearing where they shouldn't, and those 
> values are set by `completing-read-default`, so I think it's clearly the 
> culprit.
>

By 'completing-read-default' _and_ by other completion backends that set 
minibuffer-completion-* elements and call read-from-minibuffer.  Or am I 
misunderstanding something?

If not, it means that your patch will fix the problem for 
completing-read-default, but not for other completion backends, who will 
have to resort on a similar trick to get the same effect.  IMO it would be 
better to avoid that, and to give "read-from-minibuffer" the new semantics 
that it takes some arguments from the environment and that these arguments 
are not anymore visible by all other (recursive) uses of 
read-from-minibuffer.

>> The right thing to do is to change the semantics of 
>> read-from-minibuffer (while preserving backward compatibility for a 
>> limited amount of time), in such a way it receives some of its 
>> arguments through its environment.
>
> The core problem is the fact that dynamic scoping leaks: the parameters 
> passed to `read-from-minibuffer` via dynamic scoping and up being passed 
> to all other uses of `read-from-minibuffer` which happen to take place 
> within the same dynamic extent.
>

Not with the patch I'm proposing.  What it does is the following (in 
abbreviated form):

(let ((minibuffer-local-* minibuffer-completion-*))
    (let ((minibuffer-completion-* nil))
       (internal-read-from-minibuffer ...)))

Line 1 saves the parameters in temporary variables, and line 2 resets the 
values of the parameters to nil, which means that they will not be visible 
anymore to all other uses of read-from-minibuffer within the same dynamic 
extent.  Isn't that a nice trick?

So you get all you want at once:

- receiving the arguments from the environment (thereby avoiding to add 
new explicit parameters)

- buffer-local values of the arguments on demand (thereby getting better 
semantics for callers that want it, in particular completing-read-default)

- be backward compatible the current semantics of read-from-minibufer 
(thereby avoiding to break compatibility for callers that did not adapt to 
the the new semantics)




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45474; Package emacs. Full text available.

Message received at 45474 <at> debbugs.gnu.org:


Received: (at 45474) by debbugs.gnu.org; 23 Apr 2021 13:21:14 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Apr 23 09:21:14 2021
Received: from localhost ([127.0.0.1]:36442 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lZvkA-0004po-5p
	for submit <at> debbugs.gnu.org; Fri, 23 Apr 2021 09:21:14 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:34799)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1lZvk9-0004pb-6t
 for 45474 <at> debbugs.gnu.org; Fri, 23 Apr 2021 09:21:13 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 96C8580BBA;
 Fri, 23 Apr 2021 09:21:07 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 2EE2780A9C;
 Fri, 23 Apr 2021 09:21:06 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1619184066;
 bh=TmzkOYVU16Tfq1zizXqblHR/NPZGVtXmSrOZhtdR0Kw=;
 h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
 b=D6GchzBxil8i5dZSMQ38zrn+uxnqU1Nys4bwiz6U1RRc9qIcMf/s5MWgpSFmmfKCs
 RAHb7f6u3+XjuYTT001sKM35HlEjnzb9JH/LRh1mQFfhnZQKRsh1IKNzJvgZC74GeL
 Jalrf679NgoX0H+0bM6juKYCBBzbdw/p9pzCSArGjvcrdwVJzu6Z6zylJIcjGJmyYO
 JeHTAvDZkssfTaSBGKX/fASZ0obY4IYQLZAaUoEY5a2zESwn7Yt0RwIdbYxNf0d9ks
 dMMgcJ1xSX8EvLiCvuwhoUrti2HV1qy77i67HXmwbfpHhLs1bTjvSkW0JNQOlSB1Ja
 T3UREgGggrThA==
Received: from alfajor (104-222-126-84.cpe.teksavvy.com [104.222.126.84])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id C7B0012017B;
 Fri, 23 Apr 2021 09:21:05 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Gregory Heytings <gregory@HIDDEN>
Subject: Re: bug#45474: Icomplete exhibiting in recursive minibuffer when it
 =?utf-8?Q?shouldn=E2=80=99t?=
Message-ID: <jwvmttp9mb4.fsf-monnier+emacs@HIDDEN>
References: <fv2zojtus7b0tz.fsf@HIDDEN> <3ed97a9c53e0a5d4fef8@HIDDEN>
 <87fszrz21d.fsf@HIDDEN>
 <3ed97a9c530093aca93d@HIDDEN>
 <7dee3f4235d331cab291@HIDDEN> <87r1jatd34.fsf@HIDDEN>
 <7dee3f423551aaf318cb@HIDDEN> <87im4kzlfm.fsf@HIDDEN>
 <1869622e16546eafd9df@HIDDEN>
 <jwvk0p04mbj.fsf-monnier+emacs@HIDDEN>
 <871rb6np5j.fsf@HIDDEN>
 <jwvczuqrm7s.fsf-monnier+emacs@HIDDEN>
 <87lf9cepqw.fsf@HIDDEN>
 <jwvsg3iig5h.fsf-monnier+emacs@HIDDEN>
 <jwvbla6if85.fsf-monnier+emacs@HIDDEN>
 <a87041afcb5f214d96a5@HIDDEN>
 <a87041afcb505462c0d5@HIDDEN>
 <jwv35vigog8.fsf-monnier+emacs@HIDDEN>
 <a87041afcb4761711a9a@HIDDEN>
 <jwv1rb1dhyu.fsf-monnier+emacs@HIDDEN>
 <f2b9666c4a7c09220e53@HIDDEN>
Date: Fri, 23 Apr 2021 09:21:05 -0400
In-Reply-To: <f2b9666c4a7c09220e53@HIDDEN> (Gregory Heytings's message
 of "Fri, 23 Apr 2021 06:59:09 +0000")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.060 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 45474
Cc: Dario Gjorgjevski <dario.gjorgjevski@HIDDEN>, 45474 <at> debbugs.gnu.org,
 Juri Linkov <juri@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> It seems to me that my proposal is better, and here's why.  The right thing
> to do in this case is not to install a local fix in completing-read-default,
> because completing-read-default is not where the root cause of the current
> problem lies.

Hmm... that's odd: the problem has to do with values of
`minibuffer-completion-*` appearing where they shouldn't, and those
values are set by `completing-read-default`, so I think it's clearly
the culprit.

AFAIK The patch I'm proposing is (in the long term) doing The Right
Thing (tho not quite in The Right Way since it still uses
`minibuffer-with-setup-hook`, but that's an internal detail that can be
fixed in the future by changing `read-from-minibuffer` to offer some
other way to run code in the new minibuffer).

> The right thing to do is to change the semantics of
> read-from-minibuffer (while preserving backward compatibility for
> a limited amount of time), in such a way it receives some of its
> arguments through its environment.

The core problem is the fact that dynamic scoping leaks: the parameters
passed to `read-from-minibuffer` via dynamic scoping and up being passed
to all other uses of `read-from-minibuffer` which happen to take place
within the same dynamic extent.

I can't see how "The right thing to do" can be compatible with "receives
some of its arguments through its environment".
[ Note that I'm not saying that doing it is necessarily wrong for a
  short term fix, tho.  ]


        Stefan





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45474; Package emacs. Full text available.

Message received at 45474 <at> debbugs.gnu.org:


Received: (at 45474) by debbugs.gnu.org; 23 Apr 2021 13:19:58 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Apr 23 09:19:58 2021
Received: from localhost ([127.0.0.1]:36435 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lZviv-0004n6-Qq
	for submit <at> debbugs.gnu.org; Fri, 23 Apr 2021 09:19:58 -0400
Received: from eggs.gnu.org ([209.51.188.92]:53964)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1lZvit-0004mo-VB
 for 45474 <at> debbugs.gnu.org; Fri, 23 Apr 2021 09:19:57 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:52310)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1lZvin-0002rG-NK; Fri, 23 Apr 2021 09:19:49 -0400
Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3920
 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1lZvim-0004So-KK; Fri, 23 Apr 2021 09:19:49 -0400
Date: Fri, 23 Apr 2021 16:19:42 +0300
Message-Id: <837dktnno1.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <jwvsg3h9mlv.fsf-monnier+emacs@HIDDEN> (message from Stefan
 Monnier on Fri, 23 Apr 2021 09:12:08 -0400)
Subject: Re: bug#45474: Icomplete exhibiting in recursive minibuffer when it
 =?utf-8?Q?shouldn=E2=80=99t?=
References: <fv2zojtus7b0tz.fsf@HIDDEN> <3ed97a9c53e0a5d4fef8@HIDDEN>
 <87fszrz21d.fsf@HIDDEN>
 <3ed97a9c530093aca93d@HIDDEN>
 <7dee3f4235d331cab291@HIDDEN> <87r1jatd34.fsf@HIDDEN>
 <7dee3f423551aaf318cb@HIDDEN> <87im4kzlfm.fsf@HIDDEN>
 <1869622e16546eafd9df@HIDDEN>
 <jwvk0p04mbj.fsf-monnier+emacs@HIDDEN>
 <871rb6np5j.fsf@HIDDEN>
 <jwvczuqrm7s.fsf-monnier+emacs@HIDDEN>
 <87lf9cepqw.fsf@HIDDEN>
 <jwvsg3iig5h.fsf-monnier+emacs@HIDDEN>
 <jwvbla6if85.fsf-monnier+emacs@HIDDEN>
 <a87041afcb5f214d96a5@HIDDEN>
 <a87041afcb505462c0d5@HIDDEN>
 <jwv35vigog8.fsf-monnier+emacs@HIDDEN>
 <a87041afcb4761711a9a@HIDDEN>
 <jwv1rb1dhyu.fsf-monnier+emacs@HIDDEN> <83tunxo7pn.fsf@HIDDEN>
 <jwvsg3h9mlv.fsf-monnier+emacs@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 45474
Cc: gregory@HIDDEN, juri@HIDDEN, dario.gjorgjevski@HIDDEN,
 45474 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Stefan Monnier <monnier@HIDDEN>
> Cc: gregory@HIDDEN,  dario.gjorgjevski@HIDDEN,
>   45474 <at> debbugs.gnu.org,  juri@HIDDEN
> Date: Fri, 23 Apr 2021 09:12:08 -0400
> 
> >> > Indeed, but you said that 'minibuffer-with-setup-hook' is "fundamentally
> >> > broken and messy"...
> >> All schemes using dynamic scoping to pass the information are similarly
> >> broken&messy
> > I don't agree.
> 
> I don't know what that means, here.

It means I disagree that "all schemes using dynamic scoping to pass
the information are broken and messy".




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45474; Package emacs. Full text available.

Message received at 45474 <at> debbugs.gnu.org:


Received: (at 45474) by debbugs.gnu.org; 23 Apr 2021 13:12:28 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Apr 23 09:12:28 2021
Received: from localhost ([127.0.0.1]:36425 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lZvbg-0004bk-05
	for submit <at> debbugs.gnu.org; Fri, 23 Apr 2021 09:12:28 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:53496)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1lZvbV-0004bQ-8D
 for 45474 <at> debbugs.gnu.org; Fri, 23 Apr 2021 09:12:27 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 004EB1002F2;
 Fri, 23 Apr 2021 09:12:12 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id F3B6F1000C9;
 Fri, 23 Apr 2021 09:12:09 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1619183530;
 bh=bX1xLHVXXDg3u06UMK0O7Vy6SEThPg0QSoDJlyBbZnE=;
 h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
 b=RsUHkjjTdqJ3Me+YNYcxHeq8qT2iPioS+ti2TnHBnztJziA+J3SFAEPw75/WhYa1X
 m2i8+8bV/4lB2F6IUkKCzVA5Fj+qW8lrZ9+IVK5Ua2i9XcfmNSMahH3M5DCwfDf+1z
 fzP0ZKDpOjmnQ301QCmzw3tQmW2wUMIhwrpeprAqPVpqy0bb0so3CVCBxhdMa+ClvN
 Sh4Zt5TYuouuVgp+x10uw4DiICikKw0w+c0TwIjz1KweEd0NPJsGmjv8DR4J2/gB6Y
 0FepudJENVLZo0cSaggLnJVR1G86fT9ZExtyNHLyDcTo4b2j0dpXuMAG++42fvf1cb
 J1+u4a1vyaSjg==
Received: from alfajor (104-222-126-84.cpe.teksavvy.com [104.222.126.84])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id AF0701201E3;
 Fri, 23 Apr 2021 09:12:09 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#45474: Icomplete exhibiting in recursive minibuffer when it
 =?utf-8?Q?shouldn=E2=80=99t?=
Message-ID: <jwvsg3h9mlv.fsf-monnier+emacs@HIDDEN>
References: <fv2zojtus7b0tz.fsf@HIDDEN> <3ed97a9c53e0a5d4fef8@HIDDEN>
 <87fszrz21d.fsf@HIDDEN>
 <3ed97a9c530093aca93d@HIDDEN>
 <7dee3f4235d331cab291@HIDDEN> <87r1jatd34.fsf@HIDDEN>
 <7dee3f423551aaf318cb@HIDDEN> <87im4kzlfm.fsf@HIDDEN>
 <1869622e16546eafd9df@HIDDEN>
 <jwvk0p04mbj.fsf-monnier+emacs@HIDDEN>
 <871rb6np5j.fsf@HIDDEN>
 <jwvczuqrm7s.fsf-monnier+emacs@HIDDEN>
 <87lf9cepqw.fsf@HIDDEN>
 <jwvsg3iig5h.fsf-monnier+emacs@HIDDEN>
 <jwvbla6if85.fsf-monnier+emacs@HIDDEN>
 <a87041afcb5f214d96a5@HIDDEN>
 <a87041afcb505462c0d5@HIDDEN>
 <jwv35vigog8.fsf-monnier+emacs@HIDDEN>
 <a87041afcb4761711a9a@HIDDEN>
 <jwv1rb1dhyu.fsf-monnier+emacs@HIDDEN> <83tunxo7pn.fsf@HIDDEN>
Date: Fri, 23 Apr 2021 09:12:08 -0400
In-Reply-To: <83tunxo7pn.fsf@HIDDEN> (Eli Zaretskii's message of "Fri, 23 Apr
 2021 09:06:44 +0300")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.033 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
X-SPAM-LEVEL: 
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 45474
Cc: gregory@HIDDEN, juri@HIDDEN, dario.gjorgjevski@HIDDEN,
 45474 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

>> > Indeed, but you said that 'minibuffer-with-setup-hook' is "fundamentally
>> > broken and messy"...
>> All schemes using dynamic scoping to pass the information are similarly
>> broken&messy
> I don't agree.

I don't know what that means, here.


        Stefan





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45474; Package emacs. Full text available.

Message received at 45474 <at> debbugs.gnu.org:


Received: (at 45474) by debbugs.gnu.org; 23 Apr 2021 06:59:16 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Apr 23 02:59:16 2021
Received: from localhost ([127.0.0.1]:36063 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lZpmV-0005jW-SP
	for submit <at> debbugs.gnu.org; Fri, 23 Apr 2021 02:59:16 -0400
Received: from heytings.org ([95.142.160.155]:49834)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <gregory@HIDDEN>) id 1lZpmS-0005jL-1x
 for 45474 <at> debbugs.gnu.org; Fri, 23 Apr 2021 02:59:14 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org;
 s=20210101; t=1619161150;
 bh=8tDqAi+KtVBMzMqFxjgJevLTu/dgIhwu2BMUCIZ5Z1k=;
 h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From;
 b=lf9Y9vwMj3JYsf4qaRXUO3lOdm7/R3Ap9h+Z/w4sLbXxDu1R+6bhHzpMejPEoPTbY
 YA3B/nj5aOsv2U9ShgXh2jcrARUCLWQtym7PBgCRMCyafnszpESRP2WEftRM+yKIcQ
 x6IP9rz2tC88X1WRJjzCNWBfM7v4E9P4JssInoOUwDqTKiGtxArjQbEUYQqn9sqyXk
 Yp35aIbIT3/aLyO9whrm4dxiWg5o55kAp6pc7MgmW6h/Fgi8I/iFGrWOMzdfqWh+/o
 ySIrNMjwJezf5d/gulhZH1o6qTa9GxEQugDf3XeMQHFhPv+RCVYy87HpF6Zq0J9zB3
 6Ays4WWsm++CA==
Date: Fri, 23 Apr 2021 06:59:09 +0000
From: Gregory Heytings <gregory@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
Subject: =?UTF-8?Q?Re=3A_bug#45474=3A_Icomplete_exhibiting_in_recursive?=
 =?UTF-8?Q?_minibuffer_when_it_shouldn=E2=80=99t?=
In-Reply-To: <jwv1rb1dhyu.fsf-monnier+emacs@HIDDEN>
Message-ID: <f2b9666c4a7c09220e53@HIDDEN>
References: <fv2zojtus7b0tz.fsf@HIDDEN> <3ed97a9c53e0a5d4fef8@HIDDEN>
 <87fszrz21d.fsf@HIDDEN> <3ed97a9c530093aca93d@HIDDEN>
 <7dee3f4235d331cab291@HIDDEN> <87r1jatd34.fsf@HIDDEN>
 <7dee3f423551aaf318cb@HIDDEN>
 <87im4kzlfm.fsf@HIDDEN> <1869622e16546eafd9df@HIDDEN>
 <jwvk0p04mbj.fsf-monnier+emacs@HIDDEN> <871rb6np5j.fsf@HIDDEN>
 <jwvczuqrm7s.fsf-monnier+emacs@HIDDEN> <87lf9cepqw.fsf@HIDDEN>
 <jwvsg3iig5h.fsf-monnier+emacs@HIDDEN>
 <jwvbla6if85.fsf-monnier+emacs@HIDDEN> <a87041afcb5f214d96a5@HIDDEN>
 <a87041afcb505462c0d5@HIDDEN> <jwv35vigog8.fsf-monnier+emacs@HIDDEN>
 <a87041afcb4761711a9a@HIDDEN> <jwv1rb1dhyu.fsf-monnier+emacs@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset=us-ascii
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 45474
Cc: Dario Gjorgjevski <dario.gjorgjevski@HIDDEN>, 45474 <at> debbugs.gnu.org,
 Juri Linkov <juri@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)


>>> I have the impression that I suffer from NIH syndrome with respect to 
>>> your patch, so I'll refrain from commenting on it by and large
>>
>> I'm not sure I understand what you mean here.
>
> I mean that I dislike your proposal but can't quite say why, so I 
> suspect it's just a case of "Not Invented Here" syndrome.
>

It seems to me that my proposal is better, and here's why.  The right 
thing to do in this case is not to install a local fix in 
completing-read-default, because completing-read-default is not where the 
root cause of the current problem lies.  The right thing to do is to 
change the semantics of read-from-minibuffer (while preserving backward 
compatibility for a limited amount of time), in such a way it receives 
some of its arguments through its environment.  The latter will in the 
medium term improve the situation for all users of read-from-minibuffer.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45474; Package emacs. Full text available.

Message received at 45474 <at> debbugs.gnu.org:


Received: (at 45474) by debbugs.gnu.org; 23 Apr 2021 06:07:04 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Apr 23 02:07:04 2021
Received: from localhost ([127.0.0.1]:36025 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lZoxz-0004XG-Uk
	for submit <at> debbugs.gnu.org; Fri, 23 Apr 2021 02:07:04 -0400
Received: from eggs.gnu.org ([209.51.188.92]:51856)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1lZoxx-0004Wl-0v
 for 45474 <at> debbugs.gnu.org; Fri, 23 Apr 2021 02:07:02 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:35120)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1lZoxq-0004dS-IC; Fri, 23 Apr 2021 02:06:54 -0400
Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4926
 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1lZoxq-0008IG-0d; Fri, 23 Apr 2021 02:06:54 -0400
Date: Fri, 23 Apr 2021 09:06:44 +0300
Message-Id: <83tunxo7pn.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <jwv1rb1dhyu.fsf-monnier+emacs@HIDDEN> (message from Stefan
 Monnier on Thu, 22 Apr 2021 19:24:30 -0400)
Subject: Re: bug#45474: Icomplete exhibiting in recursive minibuffer when it
 =?utf-8?Q?shouldn=E2=80=99t?=
References: <fv2zojtus7b0tz.fsf@HIDDEN> <3ed97a9c53e0a5d4fef8@HIDDEN>
 <87fszrz21d.fsf@HIDDEN>
 <3ed97a9c530093aca93d@HIDDEN>
 <7dee3f4235d331cab291@HIDDEN> <87r1jatd34.fsf@HIDDEN>
 <7dee3f423551aaf318cb@HIDDEN> <87im4kzlfm.fsf@HIDDEN>
 <1869622e16546eafd9df@HIDDEN>
 <jwvk0p04mbj.fsf-monnier+emacs@HIDDEN>
 <871rb6np5j.fsf@HIDDEN>
 <jwvczuqrm7s.fsf-monnier+emacs@HIDDEN>
 <87lf9cepqw.fsf@HIDDEN>
 <jwvsg3iig5h.fsf-monnier+emacs@HIDDEN>
 <jwvbla6if85.fsf-monnier+emacs@HIDDEN>
 <a87041afcb5f214d96a5@HIDDEN>
 <a87041afcb505462c0d5@HIDDEN>
 <jwv35vigog8.fsf-monnier+emacs@HIDDEN>
 <a87041afcb4761711a9a@HIDDEN> <jwv1rb1dhyu.fsf-monnier+emacs@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 45474
Cc: gregory@HIDDEN, juri@HIDDEN, dario.gjorgjevski@HIDDEN,
 45474 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Stefan Monnier <monnier@HIDDEN>
> Date: Thu, 22 Apr 2021 19:24:30 -0400
> Cc: Dario Gjorgjevski <dario.gjorgjevski@HIDDEN>, 45474 <at> debbugs.gnu.org,
>  Juri Linkov <juri@HIDDEN>
> 
> > Indeed, but you said that 'minibuffer-with-setup-hook' is "fundamentally
> > broken and messy"...
> 
> All schemes using dynamic scoping to pass the information are similarly
> broken&messy

I don't agree.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45474; Package emacs. Full text available.

Message received at 45474 <at> debbugs.gnu.org:


Received: (at 45474) by debbugs.gnu.org; 22 Apr 2021 23:24:47 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Apr 22 19:24:47 2021
Received: from localhost ([127.0.0.1]:35808 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lZigh-0003GU-1K
	for submit <at> debbugs.gnu.org; Thu, 22 Apr 2021 19:24:47 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:23370)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1lZigd-0003GF-Uw
 for 45474 <at> debbugs.gnu.org; Thu, 22 Apr 2021 19:24:45 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 579E18033D;
 Thu, 22 Apr 2021 19:24:38 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id D7000801AB;
 Thu, 22 Apr 2021 19:24:31 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1619133871;
 bh=P6/p0ZZ32ZrJ8hEOIb6quUwQd1vL0UaAqrbNvixfp7A=;
 h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
 b=XtE8roOLOG8Ck31kU0lCjMGUzaIrv058zY0hyGEgq0sqDjC6ZCh7gzoGnZoa95w7K
 Ti1gzU1DBxep+FZ3EgR2lqKpVJHrtaa2swZLr0cPeRzC1bG5xRoS4YNzmFYGYKTWdS
 7WAOfUni8HuarK5Nb/BlXvaWUQTXOxUKDdIcSXEqx6P7TDxwbGN9YxxN23JvjeS4oh
 6yAdz3nMkjwDzM/lKCfPnGcW17qf6LielYB2XmJFrdvU0H9qgmy2B4Kxzak97iNHDM
 ApowvxNRqauYgHrDF797eAZAvmPTaG+3UQM3miPxoUM9gkc/oDQu0+v/WEc/BCcT3j
 2DI3iOTJVWXcg==
Received: from alfajor (104-222-126-84.cpe.teksavvy.com [104.222.126.84])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 9C0961201E0;
 Thu, 22 Apr 2021 19:24:31 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Gregory Heytings <gregory@HIDDEN>
Subject: Re: bug#45474: Icomplete exhibiting in recursive minibuffer when it
 =?utf-8?Q?shouldn=E2=80=99t?=
Message-ID: <jwv1rb1dhyu.fsf-monnier+emacs@HIDDEN>
References: <fv2zojtus7b0tz.fsf@HIDDEN> <3ed97a9c53e0a5d4fef8@HIDDEN>
 <87fszrz21d.fsf@HIDDEN>
 <3ed97a9c530093aca93d@HIDDEN>
 <7dee3f4235d331cab291@HIDDEN> <87r1jatd34.fsf@HIDDEN>
 <7dee3f423551aaf318cb@HIDDEN> <87im4kzlfm.fsf@HIDDEN>
 <1869622e16546eafd9df@HIDDEN>
 <jwvk0p04mbj.fsf-monnier+emacs@HIDDEN>
 <871rb6np5j.fsf@HIDDEN>
 <jwvczuqrm7s.fsf-monnier+emacs@HIDDEN>
 <87lf9cepqw.fsf@HIDDEN>
 <jwvsg3iig5h.fsf-monnier+emacs@HIDDEN>
 <jwvbla6if85.fsf-monnier+emacs@HIDDEN>
 <a87041afcb5f214d96a5@HIDDEN>
 <a87041afcb505462c0d5@HIDDEN>
 <jwv35vigog8.fsf-monnier+emacs@HIDDEN>
 <a87041afcb4761711a9a@HIDDEN>
Date: Thu, 22 Apr 2021 19:24:30 -0400
In-Reply-To: <a87041afcb4761711a9a@HIDDEN> (Gregory Heytings's message
 of "Thu, 22 Apr 2021 19:04:04 +0000")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.061 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 45474
Cc: Dario Gjorgjevski <dario.gjorgjevski@HIDDEN>, 45474 <at> debbugs.gnu.org,
 Juri Linkov <juri@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

>> I have the impression that I suffer from NIH syndrome with respect to your
>> patch, so I'll refrain from commenting on it by and large
> I'm not sure I understand what you mean here.

I mean that I dislike your proposal but can't quite say why, so
I suspect it's just a case of "Not Invented Here" syndrome.

> Hmmm...  That's not true, see the occurrences of
> minibuffer_completing_file_name.

Indeed, it's a hack trying to solve the exact same kind of problems
we're trying to solve.

>>>    run_hook (Qminibuffer_setup_hook);
>> As in my patch, you could use this hook to do the completion-specific part
>> of the setup.
> Indeed, but you said that 'minibuffer-with-setup-hook' is "fundamentally
> broken and messy"...

All schemes using dynamic scoping to pass the information are similarly
broken&messy, so yes, I don't like using it, but at least it's not
specific to completion.


        Stefan





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45474; Package emacs. Full text available.

Message received at 45474 <at> debbugs.gnu.org:


Received: (at 45474) by debbugs.gnu.org; 22 Apr 2021 22:10:02 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Apr 22 18:10:02 2021
Received: from localhost ([127.0.0.1]:35746 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lZhWM-0001Wo-0F
	for submit <at> debbugs.gnu.org; Thu, 22 Apr 2021 18:10:02 -0400
Received: from relay3-d.mail.gandi.net ([217.70.183.195]:40439)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <juri@HIDDEN>) id 1lZhWH-0001W2-Ua
 for 45474 <at> debbugs.gnu.org; Thu, 22 Apr 2021 18:09:58 -0400
X-Originating-IP: 91.129.102.166
Received: from mail.gandi.net (m91-129-102-166.cust.tele2.ee [91.129.102.166])
 (Authenticated sender: juri@HIDDEN)
 by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 86BA160003;
 Thu, 22 Apr 2021 22:09:50 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
Subject: Re: bug#45474: Icomplete exhibiting in recursive minibuffer when it
 =?utf-8?Q?shouldn=E2=80=99t?=
Organization: LINKOV.NET
References: <fv2zojtus7b0tz.fsf@HIDDEN> <3ed97a9c53e0a5d4fef8@HIDDEN>
 <87fszrz21d.fsf@HIDDEN>
 <3ed97a9c530093aca93d@HIDDEN>
 <7dee3f4235d331cab291@HIDDEN> <87r1jatd34.fsf@HIDDEN>
 <7dee3f423551aaf318cb@HIDDEN> <87im4kzlfm.fsf@HIDDEN>
 <1869622e16546eafd9df@HIDDEN>
 <jwvk0p04mbj.fsf-monnier+emacs@HIDDEN>
 <871rb6np5j.fsf@HIDDEN>
 <jwvczuqrm7s.fsf-monnier+emacs@HIDDEN>
 <87lf9cepqw.fsf@HIDDEN>
 <jwvsg3iig5h.fsf-monnier+emacs@HIDDEN>
 <jwvbla6if85.fsf-monnier+emacs@HIDDEN>
Date: Fri, 23 Apr 2021 00:57:56 +0300
In-Reply-To: <jwvbla6if85.fsf-monnier+emacs@HIDDEN> (Stefan Monnier's message
 of "Thu, 22 Apr 2021 10:13:22 -0400")
Message-ID: <87k0oukn3n.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 45474
Cc: Gregory Heytings <gregory@HIDDEN>,
 Dario Gjorgjevski <dario.gjorgjevski@HIDDEN>, 45474 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

> I'm more and more thinking that we should really bite the bullet and go
> for a "really buffer-local" setup, such as in the patch below.
> I'd be surprised if it doesn't introduce backward incompatibilities, but
> at least it's "The Right Thing" to do.

I've tested your new patch with tests that Gregory posted
in an earlier message that cover all cases of nested
completion and non-completion minibuffers:

  M-:       C-x C-f
  C-x C-f   M-:
  C-x C-f   C-x 8 RET
  M-:       C-x f

with

  (icomplete-mode 1)
  (setq icomplete-show-matches-on-no-input t
        enable-recursive-minibuffers t)

and everything works fine without problems.  Of course, this doesn't mean
that some corner cases still exist.  But I don't know a better way
to find out than to install it and wait for bug reports.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45474; Package emacs. Full text available.

Message received at 45474 <at> debbugs.gnu.org:


Received: (at 45474) by debbugs.gnu.org; 22 Apr 2021 20:57:30 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Apr 22 16:57:30 2021
Received: from localhost ([127.0.0.1]:35666 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lZgO9-000640-Jg
	for submit <at> debbugs.gnu.org; Thu, 22 Apr 2021 16:57:30 -0400
Received: from heytings.org ([95.142.160.155]:49330)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <gregory@HIDDEN>) id 1lZgO6-00063r-Tq
 for 45474 <at> debbugs.gnu.org; Thu, 22 Apr 2021 16:57:28 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org;
 s=20210101; t=1619125045;
 bh=UEdjQHVJskP/jaKEEX6aFZDY49TPfIsFvYTrs0wajl8=;
 h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From;
 b=VwFW4xy8STEz6YgNJOprLFkqcr8aKQBSDkzEGB45vZ8GeM0a3hpYnSBGfzWMwX6m1
 xHTCfb07xpAnG6ZwvnU8lagBUyGvtfaB9gcjqJFv2vuMcZMH05fzIwWcSKF943uKoN
 Cd3g8tu8YH25tSMeW0SpZidS8RyePFToBAm2HXw4L1aqnYsbIf3VfZTEF9H2pBiCgf
 q0kDMZQRanGCkSnGhksIEk7lYysAQCoLQGHjEcVvNrJcvyHjwhUExeb/QCCu/5CFfC
 2ghYMKCC62g9Jz8cAUY4jRznhybKcT27a2w2VbYVIMua2d+XaRrv0rIvOwGHcr17N1
 t+HogjizmzKSA==
Date: Thu, 22 Apr 2021 20:57:25 +0000
From: Gregory Heytings <gregory@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
Subject: =?UTF-8?Q?Re=3A_bug#45474=3A_Icomplete_exhibiting_in_recursive?=
 =?UTF-8?Q?_minibuffer_when_it_shouldn=E2=80=99t?=
In-Reply-To: <a87041afcbf49f2f8586@HIDDEN>
Message-ID: <a87041afcb2ed01ceec6@HIDDEN>
References: <fv2zojtus7b0tz.fsf@HIDDEN> <3ed97a9c53e0a5d4fef8@HIDDEN>
 <87fszrz21d.fsf@HIDDEN> <3ed97a9c530093aca93d@HIDDEN>
 <7dee3f4235d331cab291@HIDDEN> <87r1jatd34.fsf@HIDDEN>
 <7dee3f423551aaf318cb@HIDDEN>
 <87im4kzlfm.fsf@HIDDEN> <1869622e16546eafd9df@HIDDEN>
 <jwvk0p04mbj.fsf-monnier+emacs@HIDDEN> <871rb6np5j.fsf@HIDDEN>
 <jwvczuqrm7s.fsf-monnier+emacs@HIDDEN> <87lf9cepqw.fsf@HIDDEN>
 <jwvsg3iig5h.fsf-monnier+emacs@HIDDEN>
 <jwvbla6if85.fsf-monnier+emacs@HIDDEN> <a87041afcb5f214d96a5@HIDDEN>
 <a87041afcb505462c0d5@HIDDEN> <jwv35vigog8.fsf-monnier+emacs@HIDDEN>
 <a87041afcb4761711a9a@HIDDEN> <a87041afcbf49f2f8586@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="OyaRByHmv0"
Content-ID: <a87041afcb46140a819c@HIDDEN>
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 45474
Cc: Dario Gjorgjevski <dario.gjorgjevski@HIDDEN>, 45474 <at> debbugs.gnu.org,
 Juri Linkov <juri@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)


--OyaRByHmv0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-ID: <a87041afcb0da28ef190@HIDDEN>


>>>>    run_hook (Qminibuffer_setup_hook);
>>> 
>>> As in my patch, you could use this hook to do the completion-specific 
>>> part of the setup.
>> 
>> Indeed, but you said that 'minibuffer-with-setup-hook' is 
>> "fundamentally broken and messy"...
>
> I forgot to add that if the idea is to change the semantics of 
> read-from-minibuffer in the long term, this must happen inside 
> read-from-minibuffer, not with a minibuffer-with-setup-hook around 
> read-from-minibuffer.  What would be possible here (I think) is to move 
> this piece of code in a minibuffer-with-setup-hook inside the 
> read-from-minibuffer macro.
>

And here is the patch which does this, in case you prefer it.  AFAICS it 
is functionally equivalent to the other one.
--OyaRByHmv0
Content-Type: text/x-diff; name=Make-it-possible-to-disable-a-completion-backend-in-.patch; charset=us-ascii
Content-Transfer-Encoding: base64
Content-ID: <a87041afcb924a45297b@HIDDEN>
Content-Description: 
Content-Disposition: attachment; filename=Make-it-possible-to-disable-a-completion-backend-in-.patch

RnJvbSBlZGQ0NmMxYTJkZjZkZWEyMTU0ZWI4OTNkYTUxZWNhMWFiZDJkYTgz
IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQ0KRnJvbTogR3JlZ29yeSBIZXl0
aW5ncyA8Z3JlZ29yeUBoZXl0aW5ncy5vcmc+DQpEYXRlOiBUaHUsIDIyIEFw
ciAyMDIxIDIwOjUxOjUyICswMDAwDQpTdWJqZWN0OiBbUEFUQ0hdIE1ha2Ug
aXQgcG9zc2libGUgdG8gZGlzYWJsZSBhIGNvbXBsZXRpb24gYmFja2VuZCBp
biByZWN1cnNpdmUNCiBtaW5pYnVmZmVycw0KDQotLS0NCiBsaXNwL21pbmli
dWZmZXIuZWwgfCAgMyArKy0NCiBsaXNwL3N1YnIuZWwgICAgICAgfCAzNCAr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrDQogc3JjL2Zucy5j
ICAgICAgICAgIHwgIDYgKysrLS0tDQogc3JjL21pbmlidWYuYyAgICAgIHwg
MjAgKysrKysrKysrKysrKystLS0tLS0NCiA0IGZpbGVzIGNoYW5nZWQsIDUz
IGluc2VydGlvbnMoKyksIDEwIGRlbGV0aW9ucygtKQ0KDQpkaWZmIC0tZ2l0
IGEvbGlzcC9taW5pYnVmZmVyLmVsIGIvbGlzcC9taW5pYnVmZmVyLmVsDQpp
bmRleCA3ZGEzYzM5ZTZiLi4zNzlkYWRlZjlkIDEwMDY0NA0KLS0tIGEvbGlz
cC9taW5pYnVmZmVyLmVsDQorKysgYi9saXNwL21pbmlidWZmZXIuZWwNCkBA
IC0zODg0LDcgKzM4ODQsOCBAQCBjb21wbGV0aW5nLXJlYWQtZGVmYXVsdA0K
ICAgICAgICAgICAgICAgICA7OyBgcmVhZC1mcm9tLW1pbmlidWZmZXInIHVz
ZXMgMS1iYXNlZCBpbmRleC4NCiAgICAgICAgICAgICAgICAgKDErIChjZHIg
aW5pdGlhbC1pbnB1dCkpKSkpDQogDQotICAobGV0KiAoKG1pbmlidWZmZXIt
Y29tcGxldGlvbi10YWJsZSBjb2xsZWN0aW9uKQ0KKyAgKGxldCogKChtaW5p
YnVmZmVyLWxvY2FsLWNvbXBsZXRpb24gdCkNCisgICAgICAgICAobWluaWJ1
ZmZlci1jb21wbGV0aW9uLXRhYmxlIGNvbGxlY3Rpb24pDQogICAgICAgICAg
KG1pbmlidWZmZXItY29tcGxldGlvbi1wcmVkaWNhdGUgcHJlZGljYXRlKQ0K
ICAgICAgICAgIDs7IEZJWE1FOiBSZW1vdmUvcmVuYW1lIHRoaXMgdmFyLCBz
ZWUgdGhlIG5leHQgb25lLg0KICAgICAgICAgIChtaW5pYnVmZmVyLWNvbXBs
ZXRpb24tY29uZmlybSAodW5sZXNzIChlcSByZXF1aXJlLW1hdGNoIHQpDQpk
aWZmIC0tZ2l0IGEvbGlzcC9zdWJyLmVsIGIvbGlzcC9zdWJyLmVsDQppbmRl
eCBjMmJlMjZhMTVmLi45NzI0MjJmMzQzIDEwMDY0NA0KLS0tIGEvbGlzcC9z
dWJyLmVsDQorKysgYi9saXNwL3N1YnIuZWwNCkBAIC0yNzkxLDYgKzI3OTEs
NDAgQEAgcmVhZC1wYXNzd2QNCiAgICAgICAgICAgICAgIDs7IEFuZCBvZiBj
b3Vyc2UsIGRvbid0IGtlZXAgdGhlIHNlbnNpdGl2ZSBkYXRhIGFyb3VuZC4N
CiAgICAgICAgICAgICAgIChlcmFzZS1idWZmZXIpKSkpKSkpKQ0KIA0KKyhk
ZWZ2YXIgbWluaWJ1ZmZlci1sb2NhbC1jb21wbGV0aW9uIG5pbA0KKyAgIldo
ZXRoZXIgbWluaWJ1ZmZlciBjb21wbGV0aW9uIGVsZW1lbnRzIHNob3VsZCBi
ZWNvbWUgYnVmZmVyLWxvY2FsLg0KK1RoZSBkZWZhdWx0IGlzIG5pbCBmb3Ig
RW1hY3MgMjguICBTZXR0aW5nIHRoaXMgdmFyaWFibGUgaW4gRW1hY3MgMjkg
d2lsbA0KK2hhdmUgbm8gZWZmZWN0OyB0aGUgdmFsdWUgdCB3aWxsIGJlIGFz
c3VtZWQuDQorV2hlbiB0LCBgbWluaWJ1ZmZlci1jb21wbGV0aW9uLXRhYmxl
JywgYG1pbmlidWZmZXItY29tcGxldGlvbi1wcmVkaWNhdGUnDQorYW5kIGBt
aW5pYnVmZmVyLWNvbXBsZXRpb24tY29uZmlybScgYmVjb21lIGJ1ZmZlci1s
b2NhbCB1cG9uIGVudGVyaW5nIHRoZQ0KK21pbmlidWZmZXIsIGFuZCBhcmUg
bmlsIGluIHJlY3Vyc2l2ZSBpbnZvY2F0aW9ucyBvZiB0aGUgbWluaWJ1ZmZl
ciwgdW5sZXNzDQordGhleSBoYXZlIGJlZW4gbGV0LWJvdW5kIHRvIGEgdmFs
dWUuDQorV2hlbiBuaWwsIHRoZWlyIHZhbHVlcyBpcyBzaGFyZWQgYmV0d2Vl
biB0aGUgcmVjdXJzaXZlIGludm9jYXRpb25zIG9mIHRoZQ0KK21pbmlidWZm
ZXIsIHVubGVzcyB0aGV5IGhhdmUgYmVlbiBsZXQtYm91bmQgdG8gYW5vdGhl
ciB2YWx1ZS4iKQ0KKw0KKyhkZWZtYWNybyByZWFkLWZyb20tbWluaWJ1ZmZl
ciAoJnJlc3QgYm9keSkNCisgICJSZWFkIGEgc3RyaW5nIGZyb20gdGhlIG1p
bmlidWZmZXIgd2l0aCBgaW50ZXJuYWwtcmVhZC1mcm9tLW1pbmlidWZmZXIn
Lg0KK1NlZSBgaW50ZXJuYWwtcmVhZC1mcm9tLW1pbmlidWZmZXInIGZvciBh
IGRlc2NyaXB0aW9uIG9mIHRoZSBhcmd1bWVudHMuDQorVGhpcyBtYWNybyBl
eGlzdHMgb25seSBpbiBFbWFjcyAyOCwgZm9yIHRoZSB0cmFuc2l0aW9uIHBl
cmlvZCBkdXJpbmcgd2hpY2gNCit0aGUgZGVmYXVsdCB2YWx1ZSBvZiBgbWlu
aWJ1ZmZlci1sb2NhbC1jb21wbGV0aW9uJyBpcyBuaWwsIGFuZCB3aWxsIGJl
DQorcmVtb3ZlZCBpbiBFbWFjcyAyOS4gIExpa2V3aXNlLCBgaW50ZXJuYWwt
cmVhZC1mcm9tLW1pbmlidWZmZXInIHdpbGwgYmUNCityZW1vdmVkIGluIEVt
YWNzIDI5LCBwbGVhc2UgZG8gbm90IHVzZSBpdCBkaXJlY3RseS4iDQorICBg
KGlmIG1pbmlidWZmZXItbG9jYWwtY29tcGxldGlvbg0KKyAgICAgICAobGV0
ICgobWluaWJ1ZmZlci1sb2NhbC1jLXQgbWluaWJ1ZmZlci1jb21wbGV0aW9u
LXRhYmxlKQ0KKyAgICAgICAgICAgICAobWluaWJ1ZmZlci1sb2NhbC1jLXAg
bWluaWJ1ZmZlci1jb21wbGV0aW9uLXByZWRpY2F0ZSkNCisgICAgICAgICAg
ICAgKG1pbmlidWZmZXItbG9jYWwtYy1jIG1pbmlidWZmZXItY29tcGxldGlv
bi1jb25maXJtKSkNCisgICAgICAgICAobGV0ICgobWluaWJ1ZmZlci1jb21w
bGV0aW9uLXRhYmxlIG5pbCkNCisgICAgICAgICAgICAgICAobWluaWJ1ZmZl
ci1jb21wbGV0aW9uLXByZWRpY2F0ZSBuaWwpDQorICAgICAgICAgICAgICAg
KG1pbmlidWZmZXItY29tcGxldGlvbi1jb25maXJtIG5pbCkpDQorICAgICAg
ICAgICAobWluaWJ1ZmZlci13aXRoLXNldHVwLWhvb2sNCisgICAgICAgICAg
ICAgICAobGFtYmRhICgpDQorICAgICAgICAgICAgICAgICAoc2V0cS1sb2Nh
bCBtaW5pYnVmZmVyLWNvbXBsZXRpb24tdGFibGUgbWluaWJ1ZmZlci1sb2Nh
bC1jLXQNCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1pbmlidWZm
ZXItY29tcGxldGlvbi1wcmVkaWNhdGUgbWluaWJ1ZmZlci1sb2NhbC1jLXAN
CisgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1pbmlidWZmZXItY29t
cGxldGlvbi1jb25maXJtIG1pbmlidWZmZXItbG9jYWwtYy1jKQ0KKyAgICAg
ICAgICAgICAgICAgKHNldHEgbWluaWJ1ZmZlci1sb2NhbC1jb21wbGV0aW9u
IG5pbCkpDQorICAgICAgICAgICAgIChpbnRlcm5hbC1yZWFkLWZyb20tbWlu
aWJ1ZmZlciAsQGJvZHkpKSkpDQorICAgICAoaW50ZXJuYWwtcmVhZC1mcm9t
LW1pbmlidWZmZXIgLEBib2R5KSkpDQorDQogKGRlZnZhciByZWFkLW51bWJl
ci1oaXN0b3J5IG5pbA0KICAgIlRoZSBkZWZhdWx0IGhpc3RvcnkgZm9yIHRo
ZSBgcmVhZC1udW1iZXInIGZ1bmN0aW9uLiIpDQogDQpkaWZmIC0tZ2l0IGEv
c3JjL2Zucy5jIGIvc3JjL2Zucy5jDQppbmRleCAxNzU4MTQ4ZmYyLi5kYjY2
NzlhODQ3IDEwMDY0NA0KLS0tIGEvc3JjL2Zucy5jDQorKysgYi9zcmMvZm5z
LmMNCkBAIC0yOTg1LDkgKzI5ODUsOSBAQCBERUZVTiAoInllcy1vci1uby1w
IiwgRnllc19vcl9ub19wLCBTeWVzX29yX25vX3AsIDEsIDEsIDAsDQogDQog
ICB3aGlsZSAoMSkNCiAgICAgew0KLSAgICAgIGFucyA9IEZkb3duY2FzZSAo
RnJlYWRfZnJvbV9taW5pYnVmZmVyIChwcm9tcHQsIFFuaWwsIFFuaWwsIFFu
aWwsDQotCQkJCQkgICAgICBReWVzX29yX25vX3BfaGlzdG9yeSwgUW5pbCwN
Ci0JCQkJCSAgICAgIFFuaWwpKTsNCisgICAgICBhbnMgPSBGZG93bmNhc2Ug
KEZpbnRlcm5hbF9yZWFkX2Zyb21fbWluaWJ1ZmZlciAocHJvbXB0LCBRbmls
LCBRbmlsLCBRbmlsLA0KKwkJCQkJCSAgICAgICBReWVzX29yX25vX3BfaGlz
dG9yeSwgUW5pbCwNCisJCQkJCQkgICAgICAgUW5pbCkpOw0KICAgICAgIGlm
IChTQ0hBUlMgKGFucykgPT0gMyAmJiAhc3RyY21wIChTU0RBVEEgKGFucyks
ICJ5ZXMiKSkNCiAJcmV0dXJuIHVuYmluZF90byAoY291bnQsIFF0KTsNCiAg
ICAgICBpZiAoU0NIQVJTIChhbnMpID09IDIgJiYgIXN0cmNtcCAoU1NEQVRB
IChhbnMpLCAibm8iKSkNCmRpZmYgLS1naXQgYS9zcmMvbWluaWJ1Zi5jIGIv
c3JjL21pbmlidWYuYw0KaW5kZXggMWE2MzdjODZhZC4uOTBmMzI5ZGRiMiAx
MDA2NDQNCi0tLSBhL3NyYy9taW5pYnVmLmMNCisrKyBiL3NyYy9taW5pYnVm
LmMNCkBAIC0xMjMxLDkgKzEyMzEsMTcgQEAgYmFyZl9pZl9pbnRlcmFjdGlv
bl9pbmhpYml0ZWQgKHZvaWQpDQogICAgIHhzaWduYWwwIChRaW5oaWJpdGVk
X2ludGVyYWN0aW9uKTsNCiB9DQogDQotREVGVU4gKCJyZWFkLWZyb20tbWlu
aWJ1ZmZlciIsIEZyZWFkX2Zyb21fbWluaWJ1ZmZlciwNCi0gICAgICAgU3Jl
YWRfZnJvbV9taW5pYnVmZmVyLCAxLCA3LCAwLA0KK0RFRlVOICgiaW50ZXJu
YWwtcmVhZC1mcm9tLW1pbmlidWZmZXIiLCBGaW50ZXJuYWxfcmVhZF9mcm9t
X21pbmlidWZmZXIsDQorICAgICAgIFNpbnRlcm5hbF9yZWFkX2Zyb21fbWlu
aWJ1ZmZlciwgMSwgNywgMCwNCiAgICAgICAgZG9jOiAvKiBSZWFkIGEgc3Ry
aW5nIGZyb20gdGhlIG1pbmlidWZmZXIsIHByb21wdGluZyB3aXRoIHN0cmlu
ZyBQUk9NUFQuDQorDQorV2FybmluZzogRG8gbm90IHVzZSB0aGlzIGZ1bmN0
aW9uIGRpcmVjdGx5LCB1c2UgYHJlYWQtZnJvbS1taW5pYnVmZmVyJw0KK2lu
c3RlYWQsIHdpdGggdGhlIGFyZ3VtZW50cyBkZXNjcmliZWQgYmVsb3cuICBU
aGUgYHJlYWQtZnJvbS1taW5pYnVmZmVyJw0KK21hY3JvIGV4aXN0cyBvbmx5
IGluIEVtYWNzIDI4IGZvciB0aGUgdHJhbnNpdGlvbiBwZXJpb2QgZHVyaW5n
IHdoaWNoIHRoZQ0KK2RlZmF1bHQgdmFsdWUgb2YgYG1pbmlidWZmZXItbG9j
YWwtY29tcGxldGlvbicgaXMgbmlsLCBpdCB3aWxsIGJlIHJlbW92ZWQNCitp
biBFbWFjcyAyOSwgYW5kIGBpbnRlcm5hbC0tcmVhZC1mcm9tLW1pbmlidWZm
ZXInIHdpbGwgYmVjb21lDQorYHJlYWQtZnJvbS1taW5pYnVmZmVyJyBhZ2Fp
bi4NCisNCiBUaGUgb3B0aW9uYWwgc2Vjb25kIGFyZyBJTklUSUFMLUNPTlRF
TlRTIGlzIGFuIG9ic29sZXRlIGFsdGVybmF0aXZlIHRvDQogICBERUZBVUxU
LVZBTFVFLiAgSXQgbm9ybWFsbHkgc2hvdWxkIGJlIG5pbCBpbiBuZXcgY29k
ZSwgZXhjZXB0IHdoZW4NCiAgIEhJU1QgaXMgYSBjb25zLiAgSXQgaXMgZGlz
Y3Vzc2VkIGluIG1vcmUgZGV0YWlsIGJlbG93Lg0KQEAgLTEzNTIsOSArMTM2
MCw5IEBAIERFRlVOICgicmVhZC1zdHJpbmciLCBGcmVhZF9zdHJpbmcsIFNy
ZWFkX3N0cmluZywgMSwgNSwgMCwNCiAgICAgIEZJWE1FOiBgbWluaWJ1ZmZl
ci1jb21wbGV0aW9uLXRhYmxlJyBzaG91bGQgYmUgYnVmZmVyLWxvY2FsIGlu
c3RlYWQuICAqLw0KICAgc3BlY2JpbmQgKFFtaW5pYnVmZmVyX2NvbXBsZXRp
b25fdGFibGUsIFFuaWwpOw0KIA0KLSAgdmFsID0gRnJlYWRfZnJvbV9taW5p
YnVmZmVyIChwcm9tcHQsIGluaXRpYWxfaW5wdXQsIFFuaWwsDQotCQkJICAg
ICAgIFFuaWwsIGhpc3RvcnksIGRlZmF1bHRfdmFsdWUsDQotCQkJICAgICAg
IGluaGVyaXRfaW5wdXRfbWV0aG9kKTsNCisgIHZhbCA9IEZpbnRlcm5hbF9y
ZWFkX2Zyb21fbWluaWJ1ZmZlciAocHJvbXB0LCBpbml0aWFsX2lucHV0LCBR
bmlsLA0KKwkJCQkgICAgICAgIFFuaWwsIGhpc3RvcnksIGRlZmF1bHRfdmFs
dWUsDQorCQkJCSAgICAgICAgaW5oZXJpdF9pbnB1dF9tZXRob2QpOw0KICAg
aWYgKFNUUklOR1AgKHZhbCkgJiYgU0NIQVJTICh2YWwpID09IDAgJiYgISBO
SUxQIChkZWZhdWx0X3ZhbHVlKSkNCiAgICAgdmFsID0gQ09OU1AgKGRlZmF1
bHRfdmFsdWUpID8gWENBUiAoZGVmYXVsdF92YWx1ZSkgOiBkZWZhdWx0X3Zh
bHVlOw0KICAgcmV0dXJuIHVuYmluZF90byAoY291bnQsIHZhbCk7DQpAQCAt
MjQ4Nyw3ICsyNDk1LDcgQEAgc3ltc19vZl9taW5pYnVmICh2b2lkKQ0KIA0K
ICAgZGVmc3ViciAoJlNhY3RpdmVfbWluaWJ1ZmZlcl93aW5kb3cpOw0KICAg
ZGVmc3ViciAoJlNzZXRfbWluaWJ1ZmZlcl93aW5kb3cpOw0KLSAgZGVmc3Vi
ciAoJlNyZWFkX2Zyb21fbWluaWJ1ZmZlcik7DQorICBkZWZzdWJyICgmU2lu
dGVybmFsX3JlYWRfZnJvbV9taW5pYnVmZmVyKTsNCiAgIGRlZnN1YnIgKCZT
cmVhZF9zdHJpbmcpOw0KICAgZGVmc3ViciAoJlNyZWFkX2NvbW1hbmQpOw0K
ICAgZGVmc3ViciAoJlNyZWFkX3ZhcmlhYmxlKTsNCi0tIA0KMi4zMC4yDQoN
Cg==

--OyaRByHmv0--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45474; Package emacs. Full text available.

Message received at 45474 <at> debbugs.gnu.org:


Received: (at 45474) by debbugs.gnu.org; 22 Apr 2021 19:59:07 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Apr 22 15:59:06 2021
Received: from localhost ([127.0.0.1]:35606 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lZfTe-0004ea-JI
	for submit <at> debbugs.gnu.org; Thu, 22 Apr 2021 15:59:06 -0400
Received: from heytings.org ([95.142.160.155]:49270)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <gregory@HIDDEN>) id 1lZfTc-0004eS-T8
 for 45474 <at> debbugs.gnu.org; Thu, 22 Apr 2021 15:59:06 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org;
 s=20210101; t=1619121543;
 bh=+D3cmWIHJXhnx05l1pfZPZRGvSrsG5lUeeJEhLI5EKU=;
 h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From;
 b=UXK5UZLZd8T6PUrJQbfUwIKEwSK2ZfZwd9aTaT36isMoTi6v8MYyAvaIFDJ2kFSq1
 DWvB/J1l0Smc8yzeh8qZSP29afGpa0oe/vuv5cI8XTGdOq0MRRL61jYEMGWn1ZLR4K
 TaL3Pte+U5iHlkj71UUZy9PSP8d/JMusuvNNAqxWSmaKowlwO+ScdtjzjiJLmhIkyu
 Er5yRRz6Np1dwkH7FsuAOZFuIm25HpsUFYUY63Sx9ROs95n01xN2Ou963zPvRppwlx
 zs2v3QucT5wwxnCrg+vB5T3r5K44/K2C3ndu4AZoPIQf4YrfvVOE9g2zLyRU4t0taH
 rd7MhzKHA+aLw==
Date: Thu, 22 Apr 2021 19:59:03 +0000
From: Gregory Heytings <gregory@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
Subject: =?UTF-8?Q?Re=3A_bug#45474=3A_Icomplete_exhibiting_in_recursive?=
 =?UTF-8?Q?_minibuffer_when_it_shouldn=E2=80=99t?=
In-Reply-To: <a87041afcb4761711a9a@HIDDEN>
Message-ID: <a87041afcbf49f2f8586@HIDDEN>
References: <fv2zojtus7b0tz.fsf@HIDDEN> <3ed97a9c53e0a5d4fef8@HIDDEN>
 <87fszrz21d.fsf@HIDDEN> <3ed97a9c530093aca93d@HIDDEN>
 <7dee3f4235d331cab291@HIDDEN> <87r1jatd34.fsf@HIDDEN>
 <7dee3f423551aaf318cb@HIDDEN>
 <87im4kzlfm.fsf@HIDDEN> <1869622e16546eafd9df@HIDDEN>
 <jwvk0p04mbj.fsf-monnier+emacs@HIDDEN> <871rb6np5j.fsf@HIDDEN>
 <jwvczuqrm7s.fsf-monnier+emacs@HIDDEN> <87lf9cepqw.fsf@HIDDEN>
 <jwvsg3iig5h.fsf-monnier+emacs@HIDDEN>
 <jwvbla6if85.fsf-monnier+emacs@HIDDEN> <a87041afcb5f214d96a5@HIDDEN>
 <a87041afcb505462c0d5@HIDDEN> <jwv35vigog8.fsf-monnier+emacs@HIDDEN>
 <a87041afcb4761711a9a@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 45474
Cc: Dario Gjorgjevski <dario.gjorgjevski@HIDDEN>, 45474 <at> debbugs.gnu.org,
 Juri Linkov <juri@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)


>>>    run_hook (Qminibuffer_setup_hook);
>> 
>> As in my patch, you could use this hook to do the completion-specific 
>> part of the setup.
>
> Indeed, but you said that 'minibuffer-with-setup-hook' is "fundamentally 
> broken and messy"...
>

I forgot to add that if the idea is to change the semantics of 
read-from-minibuffer in the long-term, this must happen inside 
read-from-minibuffer, not with a minibuffer-with-setup-hook around 
read-from-minibuffer.  What would be possible here (I think) is to move 
this piece of code in a minibuffer-with-setup-hook inside the 
read-from-minibuffer macro.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45474; Package emacs. Full text available.

Message received at 45474 <at> debbugs.gnu.org:


Received: (at 45474) by debbugs.gnu.org; 22 Apr 2021 19:04:09 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Apr 22 15:04:09 2021
Received: from localhost ([127.0.0.1]:35550 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lZecT-0003CP-IF
	for submit <at> debbugs.gnu.org; Thu, 22 Apr 2021 15:04:09 -0400
Received: from heytings.org ([95.142.160.155]:49206)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <gregory@HIDDEN>) id 1lZecP-0003CF-Ts
 for 45474 <at> debbugs.gnu.org; Thu, 22 Apr 2021 15:04:07 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org;
 s=20210101; t=1619118244;
 bh=jg0N043ZyzNz+OFj4EmaW6oowK7f1BIa4wf1XXNtDks=;
 h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From;
 b=IrsE8sxNZ6s1Mv1AFJ5dYHAPN6CvejCy2daPKNqrQmSm7pSVnTrmfYWEjXN19pZnC
 R5i734SS569kaxf57/9o4h0TqFxKKGSFPFx1U/ngoThFvCHtU5aaOiHrBKt1T46gTp
 yb9GNh0RwnNC0c1u6r5TMP8Kenx5CjdWSw+jr1caLtAb1U9KAp3LEEVFzCSHztltJ3
 TKMjQ511rBqzywlxOvgruAumuP47EEahtwsiNQXu5hfJn3ap92vjD/aUQYyvkEjI1x
 RN7leFmGBF5+tkN6j+Odt+Mk3RM2pcOK7VxL2M+fVpq7EKrfXyLDOYgBSoCt5f8WE0
 0IAyBTU66Lbig==
Date: Thu, 22 Apr 2021 19:04:04 +0000
From: Gregory Heytings <gregory@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
Subject: =?UTF-8?Q?Re=3A_bug#45474=3A_Icomplete_exhibiting_in_recursive?=
 =?UTF-8?Q?_minibuffer_when_it_shouldn=E2=80=99t?=
In-Reply-To: <jwv35vigog8.fsf-monnier+emacs@HIDDEN>
Message-ID: <a87041afcb4761711a9a@HIDDEN>
References: <fv2zojtus7b0tz.fsf@HIDDEN> <3ed97a9c53e0a5d4fef8@HIDDEN>
 <87fszrz21d.fsf@HIDDEN> <3ed97a9c530093aca93d@HIDDEN>
 <7dee3f4235d331cab291@HIDDEN> <87r1jatd34.fsf@HIDDEN>
 <7dee3f423551aaf318cb@HIDDEN>
 <87im4kzlfm.fsf@HIDDEN> <1869622e16546eafd9df@HIDDEN>
 <jwvk0p04mbj.fsf-monnier+emacs@HIDDEN> <871rb6np5j.fsf@HIDDEN>
 <jwvczuqrm7s.fsf-monnier+emacs@HIDDEN> <87lf9cepqw.fsf@HIDDEN>
 <jwvsg3iig5h.fsf-monnier+emacs@HIDDEN>
 <jwvbla6if85.fsf-monnier+emacs@HIDDEN> <a87041afcb5f214d96a5@HIDDEN>
 <a87041afcb505462c0d5@HIDDEN> <jwv35vigog8.fsf-monnier+emacs@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset=us-ascii
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 45474
Cc: Dario Gjorgjevski <dario.gjorgjevski@HIDDEN>, 45474 <at> debbugs.gnu.org,
 Juri Linkov <juri@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)


>
> I have the impression that I suffer from NIH syndrome with respect to 
> your patch, so I'll refrain from commenting on it by and large
>

I'm not sure I understand what you mean here.

It uses a nice trick (intermediate variables) to provide a 
backward-compatible behavior for read-from-minibuffer that would last for 
one major Emacs release (to avoid breaking external packages), while 
providing the needed feature (buffer-local completion tables) for code 
those that want to use it.  Doesn't that fit the bill?

>> diff --git a/src/minibuf.c b/src/minibuf.c
>> index 1a637c86ad..fd780bd5c1 100644
>> --- a/src/minibuf.c
>> +++ b/src/minibuf.c
>> @@ -865,6 +865,16 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
>>    if (STRINGP (input_method) && !NILP (Ffboundp (Qactivate_input_method)))
>>      call1 (Qactivate_input_method, input_method);
>>
>> +  if (! EQ (Vminibuffer_local_completion, Qnil)) {
>> +    Fmake_local_variable (Qminibuffer_completion_table);
>> +    Fset (Qminibuffer_completion_table, Vminibuffer_local_completion_table);
>> +    Fmake_local_variable (Qminibuffer_completion_predicate);
>> +    Fset (Qminibuffer_completion_predicate, Vminibuffer_local_completion_predicate);
>> +    Fmake_local_variable (Qminibuffer_completion_confirm);
>> +    Fset (Qminibuffer_completion_confirm, Vminibuffer_local_completion_confirm);
>> +    specbind (Qminibuffer_local_completion, Qnil);
>> +  }
>
> I really don't like adding knowledge of those variables to this 
> function, which so far is completely oblivious to whether the minibuffer 
> is used with completion or not.
>

Hmmm...  That's not true, see the occurrences of 
minibuffer_completing_file_name.  And that would be temporary anyway, in 
Emacs 29 this code could be removed from read_minibuf() I think.

>>    run_hook (Qminibuffer_setup_hook);
>
> As in my patch, you could use this hook to do the completion-specific 
> part of the setup.
>

Indeed, but you said that 'minibuffer-with-setup-hook' is "fundamentally 
broken and messy"...




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45474; Package emacs. Full text available.

Message received at 45474 <at> debbugs.gnu.org:


Received: (at 45474) by debbugs.gnu.org; 22 Apr 2021 18:37:00 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Apr 22 14:37:00 2021
Received: from localhost ([127.0.0.1]:35504 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lZeCB-0000Lh-RL
	for submit <at> debbugs.gnu.org; Thu, 22 Apr 2021 14:37:00 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:62677)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1lZeC9-0000LS-8k
 for 45474 <at> debbugs.gnu.org; Thu, 22 Apr 2021 14:36:58 -0400
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
 by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 9A3C9440C3A;
 Thu, 22 Apr 2021 14:36:51 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 1FC53440F1F;
 Thu, 22 Apr 2021 14:36:50 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1619116610;
 bh=I1ZbABZl08sWhqaPSUC0Z0Gh8oo+DkMO3qGTm1rr8Ik=;
 h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
 b=S7IopF4mrPcIenJZsofqgh50gIT6O4R+Wh+dOTvlLH/xSp0DjBu9jEeiPCNjqnOWd
 XJKxwjZJb2S7dN/Igmk4i6NqNXuDdn1EZo4e4quoaNE7VJxaapt2N4RC4QaWpmr/du
 ICvjb8NLHLAvqo9s4GxqgHNiYUL1P4Jm/MPgEb9zqUj/K8D5fA9bhn847Czr+QQLtm
 ET/3KcTg37xqFXVm6FONeTeZWO6zy2L5IX8hNTdhlK5Z1eJVJRK21gBCn6sd6QaMPE
 RhuZKe+XI62zH1jFAiG7pEeu0f1H44aYEhuMb1i9IUWzRKU3e2GwPYqwl/1RsgIUkc
 ReUjSBEgYSKaw==
Received: from alfajor (104-222-126-84.cpe.teksavvy.com [104.222.126.84])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id DE5FE12005B;
 Thu, 22 Apr 2021 14:36:49 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Gregory Heytings <gregory@HIDDEN>
Subject: Re: bug#45474: Icomplete exhibiting in recursive minibuffer when it
 =?utf-8?Q?shouldn=E2=80=99t?=
Message-ID: <jwv35vigog8.fsf-monnier+emacs@HIDDEN>
References: <fv2zojtus7b0tz.fsf@HIDDEN> <3ed97a9c53e0a5d4fef8@HIDDEN>
 <87fszrz21d.fsf@HIDDEN>
 <3ed97a9c530093aca93d@HIDDEN>
 <7dee3f4235d331cab291@HIDDEN> <87r1jatd34.fsf@HIDDEN>
 <7dee3f423551aaf318cb@HIDDEN> <87im4kzlfm.fsf@HIDDEN>
 <1869622e16546eafd9df@HIDDEN>
 <jwvk0p04mbj.fsf-monnier+emacs@HIDDEN>
 <871rb6np5j.fsf@HIDDEN>
 <jwvczuqrm7s.fsf-monnier+emacs@HIDDEN>
 <87lf9cepqw.fsf@HIDDEN>
 <jwvsg3iig5h.fsf-monnier+emacs@HIDDEN>
 <jwvbla6if85.fsf-monnier+emacs@HIDDEN>
 <a87041afcb5f214d96a5@HIDDEN>
 <a87041afcb505462c0d5@HIDDEN>
Date: Thu, 22 Apr 2021 14:36:49 -0400
In-Reply-To: <a87041afcb505462c0d5@HIDDEN> (Gregory Heytings's message
 of "Thu, 22 Apr 2021 15:18:49 +0000")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.095 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 45474
Cc: Dario Gjorgjevski <dario.gjorgjevski@HIDDEN>, 45474 <at> debbugs.gnu.org,
 Juri Linkov <juri@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

I have the impression that I suffer from NIH syndrome with respect to
your patch, so I'll refrain from commenting on it by and large, except
for this part:

> diff --git a/src/minibuf.c b/src/minibuf.c
> index 1a637c86ad..fd780bd5c1 100644
> --- a/src/minibuf.c
> +++ b/src/minibuf.c
> @@ -865,6 +865,16 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
>    if (STRINGP (input_method) && !NILP (Ffboundp (Qactivate_input_method)))
>      call1 (Qactivate_input_method, input_method);
>  
> +  if (! EQ (Vminibuffer_local_completion, Qnil)) {
> +    Fmake_local_variable (Qminibuffer_completion_table);
> +    Fset (Qminibuffer_completion_table, Vminibuffer_local_completion_table);
> +    Fmake_local_variable (Qminibuffer_completion_predicate);
> +    Fset (Qminibuffer_completion_predicate, Vminibuffer_local_completion_predicate);
> +    Fmake_local_variable (Qminibuffer_completion_confirm);
> +    Fset (Qminibuffer_completion_confirm, Vminibuffer_local_completion_confirm);
> +    specbind (Qminibuffer_local_completion, Qnil);
> +  }

I really don't like adding knowledge of those variables to this
function, which so far is completely oblivious to whether the
minibuffer is used with completion or not.

>    run_hook (Qminibuffer_setup_hook);

As in my patch, you could use this hook to do the completion-specific part
of the setup.


        Stefan





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45474; Package emacs. Full text available.

Message received at 45474 <at> debbugs.gnu.org:


Received: (at 45474) by debbugs.gnu.org; 22 Apr 2021 15:18:55 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Apr 22 11:18:55 2021
Received: from localhost ([127.0.0.1]:35306 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lZb6U-0001fC-Pk
	for submit <at> debbugs.gnu.org; Thu, 22 Apr 2021 11:18:55 -0400
Received: from heytings.org ([95.142.160.155]:48978)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <gregory@HIDDEN>) id 1lZb6R-0001f1-Bw
 for 45474 <at> debbugs.gnu.org; Thu, 22 Apr 2021 11:18:53 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org;
 s=20210101; t=1619104729;
 bh=xY/pK3G0S0WSKRWKc5SMIVilhYPxZrP78vJSJXg5Nao=;
 h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From;
 b=AVVVUkiXCOBECN+21WwKk3GCiO36aAeAqnhZmUR0Bf+z02tL0qyRp9Z0gPY13MQQq
 JEJX9SdyN5rYKgFuYiHqbZaDU9nrWjwllzDjR3wA9GS4q/6oBfRRYPLuJEaZfL4PCu
 X98oLz1gg/NXmkpZC7/hxUIacInoWqpc63L94dnSShYZZ1zCRmDz7g68uL4ZqkjfG0
 9cjUFilQYMmik6MMV0rFCuaQ0ho/SRTvejjN4BehcEusMhBbdQSQEnEA5n2gjn7rUc
 gYqkmQpyg44PwT2CAriYZd++O6upxwOf59Q3daghfXc15BClzjs1NAL1w9hx2EaU90
 E1mXXAc8dA6Ag==
Date: Thu, 22 Apr 2021 15:18:49 +0000
From: Gregory Heytings <gregory@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
Subject: =?UTF-8?Q?Re=3A_bug#45474=3A_Icomplete_exhibiting_in_recursive?=
 =?UTF-8?Q?_minibuffer_when_it_shouldn=E2=80=99t?=
In-Reply-To: <a87041afcb5f214d96a5@HIDDEN>
Message-ID: <a87041afcb505462c0d5@HIDDEN>
References: <fv2zojtus7b0tz.fsf@HIDDEN> <3ed97a9c53e0a5d4fef8@HIDDEN>
 <87fszrz21d.fsf@HIDDEN> <3ed97a9c530093aca93d@HIDDEN>
 <7dee3f4235d331cab291@HIDDEN> <87r1jatd34.fsf@HIDDEN>
 <7dee3f423551aaf318cb@HIDDEN>
 <87im4kzlfm.fsf@HIDDEN> <1869622e16546eafd9df@HIDDEN>
 <jwvk0p04mbj.fsf-monnier+emacs@HIDDEN> <871rb6np5j.fsf@HIDDEN>
 <jwvczuqrm7s.fsf-monnier+emacs@HIDDEN> <87lf9cepqw.fsf@HIDDEN>
 <jwvsg3iig5h.fsf-monnier+emacs@HIDDEN>
 <jwvbla6if85.fsf-monnier+emacs@HIDDEN> <a87041afcb5f214d96a5@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="Dv3wKgit5e"
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 45474
Cc: Dario Gjorgjevski <dario.gjorgjevski@HIDDEN>, 45474 <at> debbugs.gnu.org,
 Juri Linkov <juri@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)


--Dv3wKgit5e
Content-Type: text/plain; charset=us-ascii; format=flowed


>> I'm more and more thinking that we should really bite the bullet and go 
>> for a "really buffer-local" setup, such as in the patch below.
>> 
>> I'd be surprised if it doesn't introduce backward incompatibilities, 
>> but at least it's "The Right Thing" to do.
>
> Well, that's what my patch does, too, except that it delays the backward 
> incompatilibites during one Emacs major release...  (I did not include 
> minibuffer-completion-predicate and minibuffer-completion-confirm 
> because they haven't been discussed yet, but they are easy to add.)
>

And (to show that they are indeed easy to add) here is the updated patch, 
which also takes care of minibuffer-completion-predicate and 
minibuffer-completion-confirm.
--Dv3wKgit5e
Content-Type: text/x-diff; name=Make-it-possible-to-disable-a-completion-backend-in-.patch
Content-Transfer-Encoding: base64
Content-ID: <a87041afcbfcdb09d150@HIDDEN>
Content-Description: 
Content-Disposition: attachment; filename=Make-it-possible-to-disable-a-completion-backend-in-.patch

RnJvbSA1N2FjMGQ1YzA0MDhiYjgzNWViNzhmNzQ5N2E0MjVkODM5MGE3NDYw
IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQ0KRnJvbTogR3JlZ29yeSBIZXl0
aW5ncyA8Z3JlZ29yeUBoZXl0aW5ncy5vcmc+DQpEYXRlOiBUaHUsIDIyIEFw
ciAyMDIxIDE1OjEyOjU2ICswMDAwDQpTdWJqZWN0OiBbUEFUQ0hdIE1ha2Ug
aXQgcG9zc2libGUgdG8gZGlzYWJsZSBhIGNvbXBsZXRpb24gYmFja2VuZCBp
biByZWN1cnNpdmUNCiBtaW5pYnVmZmVycw0KDQotLS0NCiBsaXNwL21pbmli
dWZmZXIuZWwgfCAgMSArDQogbGlzcC9zdWJyLmVsICAgICAgIHwgMTcgKysr
KysrKysrKysrKw0KIHNyYy9mbnMuYyAgICAgICAgICB8ICA2ICsrLS0tDQog
c3JjL21pbmlidWYuYyAgICAgIHwgNTkgKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKystLS0tLQ0KIDQgZmlsZXMgY2hhbmdlZCwg
NzQgaW5zZXJ0aW9ucygrKSwgOSBkZWxldGlvbnMoLSkNCg0KZGlmZiAtLWdp
dCBhL2xpc3AvbWluaWJ1ZmZlci5lbCBiL2xpc3AvbWluaWJ1ZmZlci5lbA0K
aW5kZXggN2RhM2MzOWU2Yi4uMTc5NmI5Nzk5MCAxMDA2NDQNCi0tLSBhL2xp
c3AvbWluaWJ1ZmZlci5lbA0KKysrIGIvbGlzcC9taW5pYnVmZmVyLmVsDQpA
QCAtMzg4NSw2ICszODg1LDcgQEAgY29tcGxldGluZy1yZWFkLWRlZmF1bHQN
CiAgICAgICAgICAgICAgICAgKDErIChjZHIgaW5pdGlhbC1pbnB1dCkpKSkp
DQogDQogICAobGV0KiAoKG1pbmlidWZmZXItY29tcGxldGlvbi10YWJsZSBj
b2xsZWN0aW9uKQ0KKyAgICAgICAgIChtaW5pYnVmZmVyLWxvY2FsLWNvbXBs
ZXRpb24gdCkNCiAgICAgICAgICAobWluaWJ1ZmZlci1jb21wbGV0aW9uLXBy
ZWRpY2F0ZSBwcmVkaWNhdGUpDQogICAgICAgICAgOzsgRklYTUU6IFJlbW92
ZS9yZW5hbWUgdGhpcyB2YXIsIHNlZSB0aGUgbmV4dCBvbmUuDQogICAgICAg
ICAgKG1pbmlidWZmZXItY29tcGxldGlvbi1jb25maXJtICh1bmxlc3MgKGVx
IHJlcXVpcmUtbWF0Y2ggdCkNCmRpZmYgLS1naXQgYS9saXNwL3N1YnIuZWwg
Yi9saXNwL3N1YnIuZWwNCmluZGV4IGMyYmUyNmExNWYuLjI0MTRmNjA5NDAg
MTAwNjQ0DQotLS0gYS9saXNwL3N1YnIuZWwNCisrKyBiL2xpc3Avc3Vici5l
bA0KQEAgLTI3OTEsNiArMjc5MSwyMyBAQCByZWFkLXBhc3N3ZA0KICAgICAg
ICAgICAgICAgOzsgQW5kIG9mIGNvdXJzZSwgZG9uJ3Qga2VlcCB0aGUgc2Vu
c2l0aXZlIGRhdGEgYXJvdW5kLg0KICAgICAgICAgICAgICAgKGVyYXNlLWJ1
ZmZlcikpKSkpKSkpDQogDQorKGRlZm1hY3JvIHJlYWQtZnJvbS1taW5pYnVm
ZmVyICgmcmVzdCBib2R5KQ0KKyAgIlJlYWQgYSBzdHJpbmcgZnJvbSB0aGUg
bWluaWJ1ZmZlciB3aXRoIGBpbnRlcm5hbC1yZWFkLWZyb20tbWluaWJ1ZmZl
cicuDQorU2VlIGBpbnRlcm5hbC1yZWFkLWZyb20tbWluaWJ1ZmZlcicgZm9y
IGEgZGVzY3JpcHRpb24gb2YgdGhlIGFyZ3VtZW50cy4NCitUaGlzIG1hY3Jv
IGV4aXN0cyBvbmx5IGluIEVtYWNzIDI4LCBmb3IgdGhlIHRyYW5zaXRpb24g
cGVyaW9kIGR1cmluZyB3aGljaA0KK3RoZSBkZWZhdWx0IHZhbHVlIG9mIGBt
aW5pYnVmZmVyLWxvY2FsLWNvbXBsZXRpb24nIGlzIG5pbCwgYW5kIHdpbGwg
YmUNCityZW1vdmVkIGluIEVtYWNzIDI5LiAgTGlrZXdpc2UsIGBpbnRlcm5h
bC1yZWFkLWZyb20tbWluaWJ1ZmZlcicgd2lsbCBiZQ0KK3JlbW92ZWQgaW4g
RW1hY3MgMjksIHBsZWFzZSBkbyBub3QgdXNlIGl0IGRpcmVjdGx5LiINCisg
IGAoaWYgbWluaWJ1ZmZlci1sb2NhbC1jb21wbGV0aW9uDQorICAgICAgIChs
ZXQgKChtaW5pYnVmZmVyLWxvY2FsLWNvbXBsZXRpb24tdGFibGUgbWluaWJ1
ZmZlci1jb21wbGV0aW9uLXRhYmxlKQ0KKyAgICAgICAgICAgICAobWluaWJ1
ZmZlci1sb2NhbC1jb21wbGV0aW9uLXByZWRpY2F0ZSBtaW5pYnVmZmVyLWNv
bXBsZXRpb24tcHJlZGljYXRlKQ0KKyAgICAgICAgICAgICAobWluaWJ1ZmZl
ci1sb2NhbC1jb21wbGV0aW9uLWNvbmZpcm0gbWluaWJ1ZmZlci1jb21wbGV0
aW9uLWNvbmZpcm0pKQ0KKyAgICAgICAgIChsZXQgKChtaW5pYnVmZmVyLWNv
bXBsZXRpb24tdGFibGUgbmlsKQ0KKyAgICAgICAgICAgICAgIChtaW5pYnVm
ZmVyLWNvbXBsZXRpb24tcHJlZGljYXRlIG5pbCkNCisgICAgICAgICAgICAg
ICAobWluaWJ1ZmZlci1jb21wbGV0aW9uLWNvbmZpcm0gbmlsKSkNCisgICAg
ICAgICAgIChpbnRlcm5hbC1yZWFkLWZyb20tbWluaWJ1ZmZlciAsQGJvZHkp
KSkNCisgICAgIChpbnRlcm5hbC1yZWFkLWZyb20tbWluaWJ1ZmZlciAsQGJv
ZHkpKSkNCisNCiAoZGVmdmFyIHJlYWQtbnVtYmVyLWhpc3RvcnkgbmlsDQog
ICAiVGhlIGRlZmF1bHQgaGlzdG9yeSBmb3IgdGhlIGByZWFkLW51bWJlcicg
ZnVuY3Rpb24uIikNCiANCmRpZmYgLS1naXQgYS9zcmMvZm5zLmMgYi9zcmMv
Zm5zLmMNCmluZGV4IDE3NTgxNDhmZjIuLmRiNjY3OWE4NDcgMTAwNjQ0DQot
LS0gYS9zcmMvZm5zLmMNCisrKyBiL3NyYy9mbnMuYw0KQEAgLTI5ODUsOSAr
Mjk4NSw5IEBAIERFRlVOICgieWVzLW9yLW5vLXAiLCBGeWVzX29yX25vX3As
IFN5ZXNfb3Jfbm9fcCwgMSwgMSwgMCwNCiANCiAgIHdoaWxlICgxKQ0KICAg
ICB7DQotICAgICAgYW5zID0gRmRvd25jYXNlIChGcmVhZF9mcm9tX21pbmli
dWZmZXIgKHByb21wdCwgUW5pbCwgUW5pbCwgUW5pbCwNCi0JCQkJCSAgICAg
IFF5ZXNfb3Jfbm9fcF9oaXN0b3J5LCBRbmlsLA0KLQkJCQkJICAgICAgUW5p
bCkpOw0KKyAgICAgIGFucyA9IEZkb3duY2FzZSAoRmludGVybmFsX3JlYWRf
ZnJvbV9taW5pYnVmZmVyIChwcm9tcHQsIFFuaWwsIFFuaWwsIFFuaWwsDQor
CQkJCQkJICAgICAgIFF5ZXNfb3Jfbm9fcF9oaXN0b3J5LCBRbmlsLA0KKwkJ
CQkJCSAgICAgICBRbmlsKSk7DQogICAgICAgaWYgKFNDSEFSUyAoYW5zKSA9
PSAzICYmICFzdHJjbXAgKFNTREFUQSAoYW5zKSwgInllcyIpKQ0KIAlyZXR1
cm4gdW5iaW5kX3RvIChjb3VudCwgUXQpOw0KICAgICAgIGlmIChTQ0hBUlMg
KGFucykgPT0gMiAmJiAhc3RyY21wIChTU0RBVEEgKGFucyksICJubyIpKQ0K
ZGlmZiAtLWdpdCBhL3NyYy9taW5pYnVmLmMgYi9zcmMvbWluaWJ1Zi5jDQpp
bmRleCAxYTYzN2M4NmFkLi5mZDc4MGJkNWMxIDEwMDY0NA0KLS0tIGEvc3Jj
L21pbmlidWYuYw0KKysrIGIvc3JjL21pbmlidWYuYw0KQEAgLTg2NSw2ICs4
NjUsMTYgQEAgcmVhZF9taW5pYnVmIChMaXNwX09iamVjdCBtYXAsIExpc3Bf
T2JqZWN0IGluaXRpYWwsIExpc3BfT2JqZWN0IHByb21wdCwNCiAgIGlmIChT
VFJJTkdQIChpbnB1dF9tZXRob2QpICYmICFOSUxQIChGZmJvdW5kcCAoUWFj
dGl2YXRlX2lucHV0X21ldGhvZCkpKQ0KICAgICBjYWxsMSAoUWFjdGl2YXRl
X2lucHV0X21ldGhvZCwgaW5wdXRfbWV0aG9kKTsNCiANCisgIGlmICghIEVR
IChWbWluaWJ1ZmZlcl9sb2NhbF9jb21wbGV0aW9uLCBRbmlsKSkgew0KKyAg
ICBGbWFrZV9sb2NhbF92YXJpYWJsZSAoUW1pbmlidWZmZXJfY29tcGxldGlv
bl90YWJsZSk7DQorICAgIEZzZXQgKFFtaW5pYnVmZmVyX2NvbXBsZXRpb25f
dGFibGUsIFZtaW5pYnVmZmVyX2xvY2FsX2NvbXBsZXRpb25fdGFibGUpOw0K
KyAgICBGbWFrZV9sb2NhbF92YXJpYWJsZSAoUW1pbmlidWZmZXJfY29tcGxl
dGlvbl9wcmVkaWNhdGUpOw0KKyAgICBGc2V0IChRbWluaWJ1ZmZlcl9jb21w
bGV0aW9uX3ByZWRpY2F0ZSwgVm1pbmlidWZmZXJfbG9jYWxfY29tcGxldGlv
bl9wcmVkaWNhdGUpOw0KKyAgICBGbWFrZV9sb2NhbF92YXJpYWJsZSAoUW1p
bmlidWZmZXJfY29tcGxldGlvbl9jb25maXJtKTsNCisgICAgRnNldCAoUW1p
bmlidWZmZXJfY29tcGxldGlvbl9jb25maXJtLCBWbWluaWJ1ZmZlcl9sb2Nh
bF9jb21wbGV0aW9uX2NvbmZpcm0pOw0KKyAgICBzcGVjYmluZCAoUW1pbmli
dWZmZXJfbG9jYWxfY29tcGxldGlvbiwgUW5pbCk7DQorICB9DQorDQogICBy
dW5faG9vayAoUW1pbmlidWZmZXJfc2V0dXBfaG9vayk7DQogDQogICAvKiBE
b24ndCBhbGxvdyB0aGUgdXNlciB0byB1bmRvIHBhc3QgdGhpcyBwb2ludC4g
ICovDQpAQCAtMTIzMSw5ICsxMjQxLDE2IEBAIGJhcmZfaWZfaW50ZXJhY3Rp
b25faW5oaWJpdGVkICh2b2lkKQ0KICAgICB4c2lnbmFsMCAoUWluaGliaXRl
ZF9pbnRlcmFjdGlvbik7DQogfQ0KIA0KLURFRlVOICgicmVhZC1mcm9tLW1p
bmlidWZmZXIiLCBGcmVhZF9mcm9tX21pbmlidWZmZXIsDQotICAgICAgIFNy
ZWFkX2Zyb21fbWluaWJ1ZmZlciwgMSwgNywgMCwNCitERUZVTiAoImludGVy
bmFsLXJlYWQtZnJvbS1taW5pYnVmZmVyIiwgRmludGVybmFsX3JlYWRfZnJv
bV9taW5pYnVmZmVyLA0KKyAgICAgICBTaW50ZXJuYWxfcmVhZF9mcm9tX21p
bmlidWZmZXIsIDEsIDcsIDAsDQogICAgICAgIGRvYzogLyogUmVhZCBhIHN0
cmluZyBmcm9tIHRoZSBtaW5pYnVmZmVyLCBwcm9tcHRpbmcgd2l0aCBzdHJp
bmcgUFJPTVBULg0KKw0KK05vdGU6IERvIG5vdCB1c2UgdGhpcyBmdW5jdGlv
biBkaXJlY3RseSwgdXNlIGByZWFkLWZyb20tbWluaWJ1ZmZlcicgaW5zdGVh
ZCwNCit3aGl0aCB0aGUgYXJndW1lbnRzIGRlc2NyaWJlZCBiZWxvdy4gIFRo
ZSBgcmVhZC1mcm9tLW1pbmlidWZmZXInIG1hY3JvIGV4aXN0cw0KK29ubHkg
aW4gRW1hY3MgMjggZm9yIHRoZSB0cmFuc2l0aW9uIHBlcmlvZCBkdXJpbmcg
d2hpY2ggdGhlIGRlZmF1bHQgdmFsdWUgb2YNCitgbWluaWJ1ZmZlci1sb2Nh
bC1jb21wbGV0aW9uJyBpcyBuaWwsIGl0IHdpbGwgYmUgcmVtb3ZlZCBpbiBF
bWFjcyAyOSwgYW5kDQorYGludGVybmFsLXJlYWQtZnJvbS1taW5pYnVmZmVy
JyB3aWxsIGJlY29tZSBgcmVhZC1mcm9tLW1pbmlidWZmZXInIGFnYWluLg0K
Kw0KIFRoZSBvcHRpb25hbCBzZWNvbmQgYXJnIElOSVRJQUwtQ09OVEVOVFMg
aXMgYW4gb2Jzb2xldGUgYWx0ZXJuYXRpdmUgdG8NCiAgIERFRkFVTFQtVkFM
VUUuICBJdCBub3JtYWxseSBzaG91bGQgYmUgbmlsIGluIG5ldyBjb2RlLCBl
eGNlcHQgd2hlbg0KICAgSElTVCBpcyBhIGNvbnMuICBJdCBpcyBkaXNjdXNz
ZWQgaW4gbW9yZSBkZXRhaWwgYmVsb3cuDQpAQCAtMTM1Miw5ICsxMzY5LDkg
QEAgREVGVU4gKCJyZWFkLXN0cmluZyIsIEZyZWFkX3N0cmluZywgU3JlYWRf
c3RyaW5nLCAxLCA1LCAwLA0KICAgICAgRklYTUU6IGBtaW5pYnVmZmVyLWNv
bXBsZXRpb24tdGFibGUnIHNob3VsZCBiZSBidWZmZXItbG9jYWwgaW5zdGVh
ZC4gICovDQogICBzcGVjYmluZCAoUW1pbmlidWZmZXJfY29tcGxldGlvbl90
YWJsZSwgUW5pbCk7DQogDQotICB2YWwgPSBGcmVhZF9mcm9tX21pbmlidWZm
ZXIgKHByb21wdCwgaW5pdGlhbF9pbnB1dCwgUW5pbCwNCi0JCQkgICAgICAg
UW5pbCwgaGlzdG9yeSwgZGVmYXVsdF92YWx1ZSwNCi0JCQkgICAgICAgaW5o
ZXJpdF9pbnB1dF9tZXRob2QpOw0KKyAgdmFsID0gRmludGVybmFsX3JlYWRf
ZnJvbV9taW5pYnVmZmVyIChwcm9tcHQsIGluaXRpYWxfaW5wdXQsIFFuaWws
DQorCQkJCSAgICAgICAgUW5pbCwgaGlzdG9yeSwgZGVmYXVsdF92YWx1ZSwN
CisJCQkJICAgICAgICBpbmhlcml0X2lucHV0X21ldGhvZCk7DQogICBpZiAo
U1RSSU5HUCAodmFsKSAmJiBTQ0hBUlMgKHZhbCkgPT0gMCAmJiAhIE5JTFAg
KGRlZmF1bHRfdmFsdWUpKQ0KICAgICB2YWwgPSBDT05TUCAoZGVmYXVsdF92
YWx1ZSkgPyBYQ0FSIChkZWZhdWx0X3ZhbHVlKSA6IGRlZmF1bHRfdmFsdWU7
DQogICByZXR1cm4gdW5iaW5kX3RvIChjb3VudCwgdmFsKTsNCkBAIC0yMjgy
LDYgKzIyOTksOSBAQCBzeW1zX29mX21pbmlidWYgKHZvaWQpDQogICBGc2V0
IChRbWluaWJ1ZmZlcl9kZWZhdWx0LCBRbmlsKTsNCiANCiAgIERFRlNZTSAo
UW1pbmlidWZmZXJfY29tcGxldGlvbl90YWJsZSwgIm1pbmlidWZmZXItY29t
cGxldGlvbi10YWJsZSIpOw0KKyAgREVGU1lNIChRbWluaWJ1ZmZlcl9jb21w
bGV0aW9uX3ByZWRpY2F0ZSwgIm1pbmlidWZmZXItY29tcGxldGlvbi1wcmVk
aWNhdGUiKTsNCisgIERFRlNZTSAoUW1pbmlidWZmZXJfY29tcGxldGlvbl9j
b25maXJtLCAibWluaWJ1ZmZlci1jb21wbGV0aW9uLWNvbmZpcm0iKTsNCisg
IERFRlNZTSAoUW1pbmlidWZmZXJfbG9jYWxfY29tcGxldGlvbiwgIm1pbmli
dWZmZXItbG9jYWwtY29tcGxldGlvbiIpOw0KIA0KICAgc3RhdGljcHJvICgm
bGFzdF9taW5pYnVmX3N0cmluZyk7DQogDQpAQCAtMjQxNSw2ICsyNDM1LDMz
IEBAIHN5bXNfb2ZfbWluaWJ1ZiAodm9pZCkNCiAgY29tcGxldGlvbiBjb21t
YW5kcyBsaXN0ZWQgaW4gYG1pbmlidWZmZXItY29uZmlybS1leGl0LWNvbW1h
bmRzJy4gICovKTsNCiAgIFZtaW5pYnVmZmVyX2NvbXBsZXRpb25fY29uZmly
bSA9IFFuaWw7DQogDQorICBERUZWQVJfTElTUCAoIm1pbmlidWZmZXItbG9j
YWwtY29tcGxldGlvbiIsIFZtaW5pYnVmZmVyX2xvY2FsX2NvbXBsZXRpb24s
DQorCSAgICAgICBkb2M6IC8qIFdoZXRoZXIgbWluaWJ1ZmZlciBjb21wbGV0
aW9uIGVsZW1lbnRzIHNob3VsZCBiZWNvbWUgYnVmZmVyLWxvY2FsLg0KK1Ro
ZSBkZWZhdWx0IGlzIG5pbCBmb3IgRW1hY3MgMjguICBTZXR0aW5nIHRoaXMg
dmFyaWFibGUgaW4gRW1hY3MgMjkgd2lsbCBoYXZlIG5vIGVmZmVjdDsNCit0
aGUgdmFsdWUgdCB3aWxsIGJlIGFzc3VtZWQuDQorV2hlbiB0LCBgbWluaWJ1
ZmZlci1jb21wbGV0aW9uLXRhYmxlJywgYG1pbmlidWZmZXItY29tcGxldGlv
bi1wcmVkaWNhdGUnIGFuZA0KK2BtaW5pYnVmZmVyLWNvbXBsZXRpb24tY29u
ZmlybScgYmVjb21lIGJ1ZmZlci1sb2NhbCB1cG9uIGVudGVyaW5nIHRoZSBt
aW5pYnVmZmVyLA0KK2FuZCBhcmUgbmlsIGluIHJlY3Vyc2l2ZSBpbnZvY2F0
aW9ucyBvZiB0aGUgbWluaWJ1ZmZlciwgdW5sZXNzIHRoZXkgaGF2ZSBiZWVu
IGxldC1ib3VuZA0KK3RvIGEgdmFsdWUuDQorV2hlbiBuaWwsIHRoZWlyIHZh
bHVlcyBpcyBzaGFyZWQgYmV0d2VlbiB0aGUgcmVjdXJzaXZlIGludm9jYXRp
b25zIG9mIHRoZSBtaW5pYnVmZmVyLA0KK3VubGVzcyB0aGV5IGhhdmUgYmVl
biBsZXQtYm91bmQgdG8gYW5vdGhlciB2YWx1ZS4gICovKTsNCisgIFZtaW5p
YnVmZmVyX2xvY2FsX2NvbXBsZXRpb24gPSBRbmlsOw0KKw0KKyAgREVGVkFS
X0xJU1AgKCJtaW5pYnVmZmVyLWxvY2FsLWNvbXBsZXRpb24tdGFibGUiLCBW
bWluaWJ1ZmZlcl9sb2NhbF9jb21wbGV0aW9uX3RhYmxlLA0KKwkgICAgICAg
ZG9jOiAvKiBUaGUgbG9jYWwgY29tcGxldGlvbiB0YWJsZSB1c2VkIGluIHRo
ZSBtaW5pYnVmZmVyLg0KK1NlZSBgbWluaWJ1ZmZlci1sb2NhbC1jb21wbGV0
aW9uJy4gICovKTsNCisgIFZtaW5pYnVmZmVyX2xvY2FsX2NvbXBsZXRpb25f
dGFibGUgPSBRbmlsOw0KKw0KKyAgREVGVkFSX0xJU1AgKCJtaW5pYnVmZmVy
LWxvY2FsLWNvbXBsZXRpb24tcHJlZGljYXRlIiwgVm1pbmlidWZmZXJfbG9j
YWxfY29tcGxldGlvbl9wcmVkaWNhdGUsDQorCSAgICAgICBkb2M6IC8qIFRo
ZSBsb2NhbCBjb21wbGV0aW9uIHByZWRpY2F0ZSB1c2VkIGluIHRoZSBtaW5p
YnVmZmVyLg0KK1NlZSBgbWluaWJ1ZmZlci1sb2NhbC1jb21wbGV0aW9uJy4g
ICovKTsNCisgIFZtaW5pYnVmZmVyX2xvY2FsX2NvbXBsZXRpb25fcHJlZGlj
YXRlID0gUW5pbDsNCisNCisgIERFRlZBUl9MSVNQICgibWluaWJ1ZmZlci1s
b2NhbC1jb21wbGV0aW9uLWNvbmZpcm0iLCBWbWluaWJ1ZmZlcl9sb2NhbF9j
b21wbGV0aW9uX2NvbmZpcm0sDQorCSAgICAgICBkb2M6IC8qIFRoZSBsb2Nh
bCBjb21wbGV0aW9uIGNvbmZpcm0gdXNlZCBpbiB0aGUgbWluaWJ1ZmZlci4N
CitTZWUgYG1pbmlidWZmZXItbG9jYWwtY29tcGxldGlvbicuICAqLyk7DQor
ICBWbWluaWJ1ZmZlcl9sb2NhbF9jb21wbGV0aW9uX2NvbmZpcm0gPSBRbmls
Ow0KKw0KICAgREVGVkFSX0xJU1AgKCJtaW5pYnVmZmVyLWNvbXBsZXRpbmct
ZmlsZS1uYW1lIiwNCiAJICAgICAgIFZtaW5pYnVmZmVyX2NvbXBsZXRpbmdf
ZmlsZV9uYW1lLA0KIAkgICAgICAgZG9jOiAvKiBOb24tbmlsIG1lYW5zIGNv
bXBsZXRpbmcgZmlsZSBuYW1lcy4gICovKTsNCkBAIC0yNDg3LDcgKzI1MzQs
NyBAQCBzeW1zX29mX21pbmlidWYgKHZvaWQpDQogDQogICBkZWZzdWJyICgm
U2FjdGl2ZV9taW5pYnVmZmVyX3dpbmRvdyk7DQogICBkZWZzdWJyICgmU3Nl
dF9taW5pYnVmZmVyX3dpbmRvdyk7DQotICBkZWZzdWJyICgmU3JlYWRfZnJv
bV9taW5pYnVmZmVyKTsNCisgIGRlZnN1YnIgKCZTaW50ZXJuYWxfcmVhZF9m
cm9tX21pbmlidWZmZXIpOw0KICAgZGVmc3ViciAoJlNyZWFkX3N0cmluZyk7
DQogICBkZWZzdWJyICgmU3JlYWRfY29tbWFuZCk7DQogICBkZWZzdWJyICgm
U3JlYWRfdmFyaWFibGUpOw0KLS0gDQoyLjMwLjINCg0K

--Dv3wKgit5e--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45474; Package emacs. Full text available.

Message received at 45474 <at> debbugs.gnu.org:


Received: (at 45474) by debbugs.gnu.org; 22 Apr 2021 15:03:44 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Apr 22 11:03:44 2021
Received: from localhost ([127.0.0.1]:35266 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lZaro-0007b6-DH
	for submit <at> debbugs.gnu.org; Thu, 22 Apr 2021 11:03:44 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:4860)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1lZark-0007ap-SR
 for 45474 <at> debbugs.gnu.org; Thu, 22 Apr 2021 11:03:43 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 3190D10050F;
 Thu, 22 Apr 2021 11:03:35 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 28964100216;
 Thu, 22 Apr 2021 11:03:33 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1619103813;
 bh=ypqczK1/1nawl37NvLaOrmJ4MlZB/Kku1TsapQpjwBQ=;
 h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
 b=Jj/uc5tTmO5rR7q9UrUco3Rh8NRoEiTbvss6mYgjLGBtfuGGFJPkHrFHXODKvQtiR
 DF0gRfrhIYxC/51EMNNQwFZUjNpRPas2h6bRzI3aZ89+ZK5I7tIN9wzRFk8xyQCNvU
 kHoFK5EVOB7gkcuxzqm8w0URJH2wmR1TEErOTgcW5tAGbjSdps73qEoPmrnBT6HbNB
 01hueSyEzudoWAQmv20L5+Mh73oVqyKq3T06PF5ui5Xv1gjE6ktCmJiOSFgXZNJGmi
 UpGkliDmVDuk8nsny8SBjij7Lw7SrKNFskixdGiL3gfjJGesb5IWF/D5eMKzNXN8NP
 5i3b7fzgTIsrg==
Received: from alfajor (104-222-126-84.cpe.teksavvy.com [104.222.126.84])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id BB8FE120283;
 Thu, 22 Apr 2021 11:03:32 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Drew Adams <drew.adams@HIDDEN>
Subject: Re: [External] : bug#45474: Icomplete exhibiting in recursive
 minibuffer when it =?utf-8?Q?shouldn=E2=80=99t?=
Message-ID: <jwvv98egy59.fsf-monnier+emacs@HIDDEN>
References: <fv2zojtus7b0tz.fsf@HIDDEN> <3ed97a9c53e0a5d4fef8@HIDDEN>
 <87fszrz21d.fsf@HIDDEN>
 <3ed97a9c530093aca93d@HIDDEN>
 <7dee3f4235d331cab291@HIDDEN> <87r1jatd34.fsf@HIDDEN>
 <7dee3f423551aaf318cb@HIDDEN> <87im4kzlfm.fsf@HIDDEN>
 <1869622e16546eafd9df@HIDDEN>
 <jwvk0p04mbj.fsf-monnier+emacs@HIDDEN>
 <SA2PR10MB44745ED4108357EC76AA7A6AF34B9@HIDDEN>
 <jwv35vo4539.fsf-monnier+emacs@HIDDEN>
 <SA2PR10MB4474642A71D8488D46B4870BF34A9@HIDDEN>
 <jwvr1j82nba.fsf-monnier+emacs@HIDDEN>
 <SA2PR10MB447493ACD79B3A73FB19D76EF34A9@HIDDEN>
 <jwvh7k31lws.fsf-monnier+emacs@HIDDEN>
 <SA2PR10MB44743A94DEACF3BC1D51E499F34A9@HIDDEN>
 <jwvo8ebz56c.fsf-monnier+emacs@HIDDEN>
 <SA2PR10MB44740E0461ACB6E20CCACD5DF34A9@HIDDEN>
Date: Thu, 22 Apr 2021 11:03:26 -0400
In-Reply-To: <SA2PR10MB44740E0461ACB6E20CCACD5DF34A9@HIDDEN>
 (Drew Adams's message of "Sun, 18 Apr 2021 23:46:01 +0000")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.029 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 45474
Cc: Gregory Heytings <gregory@HIDDEN>, Juri Linkov <juri@HIDDEN>,
 Dario Gjorgjevski <dario.gjorgjevski@HIDDEN>,
 "45474 <at> debbugs.gnu.org" <45474 <at> debbugs.gnu.org>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> And it was clear that I wasn't sure ("possibly
> misunderstanding") what you meant by that phrase.

Try the patch below,


        Stefan


diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index 7da3c39e6b9..ce136b90449 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -3884,13 +3884,7 @@ completing-read-default
                 ;; `read-from-minibuffer' uses 1-based index.
                 (1+ (cdr initial-input)))))
 
-  (let* ((minibuffer-completion-table collection)
-         (minibuffer-completion-predicate predicate)
-         ;; FIXME: Remove/rename this var, see the next one.
-         (minibuffer-completion-confirm (unless (eq require-match t)
-                                          require-match))
-         (minibuffer--require-match require-match)
-         (base-keymap (if require-match
+  (let* ((base-keymap (if require-match
                          minibuffer-local-must-match-map
                         minibuffer-local-completion-map))
          (keymap (if (memq minibuffer-completing-file-name '(nil lambda))
@@ -3903,8 +3897,17 @@ completing-read-default
                     ;; in minibuffer-local-filename-completion-map can
                     ;; override bindings in base-keymap.
                     base-keymap)))
-         (result (read-from-minibuffer prompt initial-input keymap
-                                       nil hist def inherit-input-method)))
+         (result
+          (minibuffer-with-setup-hook
+              (lambda ()
+                (setq-local minibuffer-completion-table collection)
+                (setq-local minibuffer-completion-predicate predicate)
+                ;; FIXME: Remove/rename this var, see the next one.
+                (setq-local minibuffer-completion-confirm
+                            (unless (eq require-match t) require-match))
+                (setq-local minibuffer--require-match require-match))
+            (read-from-minibuffer prompt initial-input keymap
+                                  nil hist def inherit-input-method))))
     (when (and (equal result "") def)
       (setq result (if (consp def) (car def) def)))
     result))





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45474; Package emacs. Full text available.

Message received at 45474 <at> debbugs.gnu.org:


Received: (at 45474) by debbugs.gnu.org; 22 Apr 2021 14:18:10 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Apr 22 10:18:10 2021
Received: from localhost ([127.0.0.1]:35224 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lZa9h-0004Lv-QW
	for submit <at> debbugs.gnu.org; Thu, 22 Apr 2021 10:18:10 -0400
Received: from heytings.org ([95.142.160.155]:48886)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <gregory@HIDDEN>) id 1lZa9g-0004Ln-3L
 for 45474 <at> debbugs.gnu.org; Thu, 22 Apr 2021 10:18:08 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org;
 s=20210101; t=1619101087;
 bh=nE3O4PaRwJDzY571JdkWoG4LqKduszenCTKioDR9zHE=;
 h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From;
 b=BWoGUpJj8Vzl924f4RNr1ZJZvoqN/mE11woPdQ31HWfUque6LgPFbKpaylzdPZBIN
 8WTAJsCr0wKt3I6k+gp4Hg9AiILGqHAx5mZ6IoRi4UxFyXFx8cYoLFGp8E4AYjuo68
 eZlGSBTzbu2nRnAKbwzPcSV+oR4jW8Pq5a3yZ5NF1VV/6TtsrmRwRqhB2u15EA39jv
 7X1q81ECwSILkKnsJ+uejSnxyIa4FHOOmFqTE/Qe0rlHtQxGiL1mtuaiZLEvNIsJ2n
 G0pDZZWLmGxWeLk87dE4HsefVluJlJZl6xY8TQK/1ooYBfXt4T+6qTFDb6gzBGNexI
 5mqDFGDhegUKQ==
Date: Thu, 22 Apr 2021 14:18:06 +0000
From: Gregory Heytings <gregory@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
Subject: =?UTF-8?Q?Re=3A_bug#45474=3A_Icomplete_exhibiting_in_recursive?=
 =?UTF-8?Q?_minibuffer_when_it_shouldn=E2=80=99t?=
In-Reply-To: <jwvbla6if85.fsf-monnier+emacs@HIDDEN>
Message-ID: <a87041afcb5f214d96a5@HIDDEN>
References: <fv2zojtus7b0tz.fsf@HIDDEN> <3ed97a9c53e0a5d4fef8@HIDDEN>
 <87fszrz21d.fsf@HIDDEN> <3ed97a9c530093aca93d@HIDDEN>
 <7dee3f4235d331cab291@HIDDEN> <87r1jatd34.fsf@HIDDEN>
 <7dee3f423551aaf318cb@HIDDEN>
 <87im4kzlfm.fsf@HIDDEN> <1869622e16546eafd9df@HIDDEN>
 <jwvk0p04mbj.fsf-monnier+emacs@HIDDEN> <871rb6np5j.fsf@HIDDEN>
 <jwvczuqrm7s.fsf-monnier+emacs@HIDDEN> <87lf9cepqw.fsf@HIDDEN>
 <jwvsg3iig5h.fsf-monnier+emacs@HIDDEN>
 <jwvbla6if85.fsf-monnier+emacs@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset=us-ascii
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 45474
Cc: Dario Gjorgjevski <dario.gjorgjevski@HIDDEN>, 45474 <at> debbugs.gnu.org,
 Juri Linkov <juri@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)


>
> I'm more and more thinking that we should really bite the bullet and go 
> for a "really buffer-local" setup, such as in the patch below.
>
> I'd be surprised if it doesn't introduce backward incompatibilities, but 
> at least it's "The Right Thing" to do.
>

Well, that's what my patch does, too, except that it delays the backward 
incompatilibites during one Emacs major release...  (I did not include 
minibuffer-completion-predicate and minibuffer-completion-confirm because 
they haven't been discussed yet, but they are easy to add.)




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45474; Package emacs. Full text available.

Message received at 45474 <at> debbugs.gnu.org:


Received: (at 45474) by debbugs.gnu.org; 22 Apr 2021 14:13:36 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Apr 22 10:13:36 2021
Received: from localhost ([127.0.0.1]:35209 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lZa5H-0004Da-MA
	for submit <at> debbugs.gnu.org; Thu, 22 Apr 2021 10:13:35 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:45923)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1lZa5D-0004DL-Gk
 for 45474 <at> debbugs.gnu.org; Thu, 22 Apr 2021 10:13:34 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id AF443100525;
 Thu, 22 Apr 2021 10:13:25 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 1A37A1000C9;
 Thu, 22 Apr 2021 10:13:24 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1619100804;
 bh=bWv+3Yq57D7iueJnO+Q7rhm1UN+54noM4shE+XnPmFw=;
 h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
 b=Kec0zM0FFiLtP5Ays6TSLifRQp5A+pEuzNIjGB6J1Bq3EIPmFwRgqQ6j0Q6s28hmq
 z9GpkvSylhP/yG4NaNu7W46kwS/R8ggFXZR7Vq0nisE9NrCRD2F9v6is/nkFBgheWH
 TucBMdv04PcgQD1coEvid5L5xy14Epow088QoBpwpgEhManJn5DpoK8hC/jcmsfrDi
 mjZjIZGFbFvE0HGOyT24cljZ4c0P2FtjBmeTvMkS0aZlo/SYiRjjloYgmL/a7JdFDS
 HWK6nDvb+lAerkuGpqet8w/4KwaisEz6NltXV6yGwdLTQOq7A7B3nXJfyf3br+KpZv
 l0K+mQmcnrtTQ==
Received: from alfajor (104-222-126-84.cpe.teksavvy.com [104.222.126.84])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id D3D53120175;
 Thu, 22 Apr 2021 10:13:23 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Juri Linkov <juri@HIDDEN>
Subject: Re: bug#45474: Icomplete exhibiting in recursive minibuffer when it
 =?utf-8?Q?shouldn=E2=80=99t?=
Message-ID: <jwvbla6if85.fsf-monnier+emacs@HIDDEN>
References: <fv2zojtus7b0tz.fsf@HIDDEN> <3ed97a9c53e0a5d4fef8@HIDDEN>
 <87fszrz21d.fsf@HIDDEN>
 <3ed97a9c530093aca93d@HIDDEN>
 <7dee3f4235d331cab291@HIDDEN> <87r1jatd34.fsf@HIDDEN>
 <7dee3f423551aaf318cb@HIDDEN> <87im4kzlfm.fsf@HIDDEN>
 <1869622e16546eafd9df@HIDDEN>
 <jwvk0p04mbj.fsf-monnier+emacs@HIDDEN>
 <871rb6np5j.fsf@HIDDEN>
 <jwvczuqrm7s.fsf-monnier+emacs@HIDDEN>
 <87lf9cepqw.fsf@HIDDEN>
 <jwvsg3iig5h.fsf-monnier+emacs@HIDDEN>
Date: Thu, 22 Apr 2021 10:13:22 -0400
In-Reply-To: <jwvsg3iig5h.fsf-monnier+emacs@HIDDEN> (Stefan Monnier's message
 of "Thu, 22 Apr 2021 09:54:48 -0400")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.029 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 45474
Cc: Gregory Heytings <gregory@HIDDEN>,
 Dario Gjorgjevski <dario.gjorgjevski@HIDDEN>, 45474 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

>> I tested your patch and discovered that it fails when two nested
>> minibuffers both use completion, e.g. C-x C-f C-h v raises the error:
>>
>>    Error in post-command-hook (icomplete-post-command-hook): (wrong-type-argument symbolp
>
> Indeed, it's nasty:
>
> - In the first step, we
>   - let-bind (globally) m-c-table to read-file-name-internal
>   - go to minibuf-1
>   - make it buffer-local in minibuf-1
>   - everything's dandy
> - In the second step, things get ugly
>   - we're in minibuf-1
>   - we let-bind m-c-table to help--symbol-completion-table which
>     only works buffer-locally in minibuf-1 (thus temporarily overriding
>     the value set just before).
>   - we go to minibuf-2 which still has no buffer-local setting so it
>     sees the global value that's still read-file-name-internal (because
>     of the very first part of the first step)
>   - we make it buffer-local but to this wrong value
>
> So in the end we get a wrong m-c-table in both buffers (the values are reversed!).

I'm more and more thinking that we should really bite the bullet and go
for a "really buffer-local" setup, such as in the patch below.
I'd be surprised if it doesn't introduce backward incompatibilities, but
at least it's "The Right Thing" to do.


        Stefan


diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index 7da3c39e6b9..ce136b90449 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -3884,13 +3884,7 @@ completing-read-default
                 ;; `read-from-minibuffer' uses 1-based index.
                 (1+ (cdr initial-input)))))
 
-  (let* ((minibuffer-completion-table collection)
-         (minibuffer-completion-predicate predicate)
-         ;; FIXME: Remove/rename this var, see the next one.
-         (minibuffer-completion-confirm (unless (eq require-match t)
-                                          require-match))
-         (minibuffer--require-match require-match)
-         (base-keymap (if require-match
+  (let* ((base-keymap (if require-match
                          minibuffer-local-must-match-map
                         minibuffer-local-completion-map))
          (keymap (if (memq minibuffer-completing-file-name '(nil lambda))
@@ -3903,8 +3897,17 @@ completing-read-default
                     ;; in minibuffer-local-filename-completion-map can
                     ;; override bindings in base-keymap.
                     base-keymap)))
-         (result (read-from-minibuffer prompt initial-input keymap
-                                       nil hist def inherit-input-method)))
+         (result
+          (minibuffer-with-setup-hook
+              (lambda ()
+                (setq-local minibuffer-completion-table collection)
+                (setq-local minibuffer-completion-predicate predicate)
+                ;; FIXME: Remove/rename this var, see the next one.
+                (setq-local minibuffer-completion-confirm
+                            (unless (eq require-match t) require-match))
+                (setq-local minibuffer--require-match require-match))
+            (read-from-minibuffer prompt initial-input keymap
+                                  nil hist def inherit-input-method))))
     (when (and (equal result "") def)
       (setq result (if (consp def) (car def) def)))
     result))





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45474; Package emacs. Full text available.

Message received at 45474 <at> debbugs.gnu.org:


Received: (at 45474) by debbugs.gnu.org; 22 Apr 2021 14:08:09 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Apr 22 10:08:09 2021
Received: from localhost ([127.0.0.1]:35204 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lZa01-00046D-0H
	for submit <at> debbugs.gnu.org; Thu, 22 Apr 2021 10:08:09 -0400
Received: from heytings.org ([95.142.160.155]:48854)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <gregory@HIDDEN>) id 1lZZzx-000461-0i
 for 45474 <at> debbugs.gnu.org; Thu, 22 Apr 2021 10:08:07 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org;
 s=20210101; t=1619100483;
 bh=1beXCblyp8pyQr/+CeQPBkythfVD1owiF9er8BlswLw=;
 h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From;
 b=cDLHjJcFS2hLHhVYsKCZD4bcbY6P4/2wJ8lf6FDke2mwTWWYtNnK4mXHIZlcho8Uc
 GMO0uC61q1FYzirJpS9ygjTDXHnOieQrySXqmcIUxeo8M2nTFkkCBwMSPov76L2Pem
 bru/7szNtZX8rQpLFKbuLaiEph9EnumCtwG2nTkOGw8rah9EQthf1XVjdPccGMdq3b
 Fq7cIqYD9qnGonlGUegll8E1B+VwKs9ShdpaoauiYGBR//kNsy4aGbdoAd+fUFAJBz
 pAM3mjZ1pizdV/KaJjpvRlp+AVcMyo6OKDdkVB7RxmJ8tIAmiHqquSP70FvkEvpo/r
 uBV82QZqtl43Q==
Date: Thu, 22 Apr 2021 14:08:03 +0000
From: Gregory Heytings <gregory@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
Subject: =?UTF-8?Q?Re=3A_bug#45474=3A_Icomplete_exhibiting_in_recursive?=
 =?UTF-8?Q?_minibuffer_when_it_shouldn=E2=80=99t?=
In-Reply-To: <jwvmttqiftf.fsf-monnier+emacs@HIDDEN>
Message-ID: <a87041afcbf928e65a69@HIDDEN>
References: <fv2zojtus7b0tz.fsf@HIDDEN> <3ed97a9c53e0a5d4fef8@HIDDEN>
 <87fszrz21d.fsf@HIDDEN> <3ed97a9c530093aca93d@HIDDEN>
 <7dee3f4235d331cab291@HIDDEN> <87r1jatd34.fsf@HIDDEN>
 <7dee3f423551aaf318cb@HIDDEN>
 <87im4kzlfm.fsf@HIDDEN> <1869622e16546eafd9df@HIDDEN>
 <jwvk0p04mbj.fsf-monnier+emacs@HIDDEN> <871rb6np5j.fsf@HIDDEN>
 <jwvczuqrm7s.fsf-monnier+emacs@HIDDEN> <a6e276cb03e0600b52bf@HIDDEN>
 <jwvmttqiftf.fsf-monnier+emacs@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset=us-ascii
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 45474
Cc: Dario Gjorgjevski <dario.gjorgjevski@HIDDEN>, 45474 <at> debbugs.gnu.org,
 Juri Linkov <juri@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)


>> diff --git a/src/minibuf.c b/src/minibuf.c
>> index c9831fd50f..6d4c2848f6 100644
>> --- a/src/minibuf.c
>> +++ b/src/minibuf.c
>> @@ -862,6 +862,12 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
>>    if (STRINGP (input_method) && !NILP (Ffboundp (Qactivate_input_method)))
>>      call1 (Qactivate_input_method, input_method);
>>
>> +  if (! EQ (Vminibuffer_local_completion_table, Qnil)) {
>> +    Fmake_local_variable (Qminibuffer_completion_table);
>> +    Fset (Qminibuffer_completion_table, Vminibuffer_local_completion_table);
>> +    specbind (Qminibuffer_local_completion_table, Qnil);
>> +  }
>> +
>>    run_hook (Qminibuffer_setup_hook);
>
> I'm afraid this will suffer a similar problem to the one Juri spotted in 
> my code.
>

I'm glad to tell you that it does not ;-)  I tested this thoroughly, of 
course it's possible that something is still wrong, but I tried many 
combinations and it seems to Just Work^TM.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45474; Package emacs. Full text available.

Message received at 45474 <at> debbugs.gnu.org:


Received: (at 45474) by debbugs.gnu.org; 22 Apr 2021 13:56:50 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Apr 22 09:56:50 2021
Received: from localhost ([127.0.0.1]:35196 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lZZp4-0001gR-Ha
	for submit <at> debbugs.gnu.org; Thu, 22 Apr 2021 09:56:50 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:6967)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1lZZp2-0001gH-Mv
 for 45474 <at> debbugs.gnu.org; Thu, 22 Apr 2021 09:56:49 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 605D1100525;
 Thu, 22 Apr 2021 09:56:43 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 0B4241000C9;
 Thu, 22 Apr 2021 09:56:42 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1619099802;
 bh=jz0lxj6xhLh0eZKt2TYxAUJ5ureSQCAovhW9nGhpf1c=;
 h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
 b=ExnTMuwy3Wo6Aav7AicvNwTN0jfzq6vU6hhaoo4w81mZl1VnfZaVjJqcNRJjcU0nr
 lpM08FvUDV6xTigsBOh0lLgcG/Dpa7bYqvU4+gavvOwqRAWu2ohnNFUQR3nhx5MowD
 ykZmP4u7r4mfmhPUDJGSU5zpwcr/urBu7Xduekce1ce9asfNZAoWqQ3SdEEW/Y15gN
 5h10JU6U7qDLcjVe4E3Vx8C6qWTZ7oSN/r9Cnh5CktXfH9FXZwbBh4hJhUJBeXPbcf
 kU8zVOqoVBfLJ0QjdFPir2PO3XrPmGM40xHk9oxD2vmFCGE24xxsaMlZC2zaJEAc+8
 UKk+H8i9Ta6PQ==
Received: from alfajor (104-222-126-84.cpe.teksavvy.com [104.222.126.84])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 78C73120175;
 Thu, 22 Apr 2021 09:56:41 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Gregory Heytings <gregory@HIDDEN>
Subject: Re: bug#45474: Icomplete exhibiting in recursive minibuffer when it
 =?utf-8?Q?shouldn=E2=80=99t?=
Message-ID: <jwvmttqiftf.fsf-monnier+emacs@HIDDEN>
References: <fv2zojtus7b0tz.fsf@HIDDEN> <3ed97a9c53e0a5d4fef8@HIDDEN>
 <87fszrz21d.fsf@HIDDEN>
 <3ed97a9c530093aca93d@HIDDEN>
 <7dee3f4235d331cab291@HIDDEN> <87r1jatd34.fsf@HIDDEN>
 <7dee3f423551aaf318cb@HIDDEN> <87im4kzlfm.fsf@HIDDEN>
 <1869622e16546eafd9df@HIDDEN>
 <jwvk0p04mbj.fsf-monnier+emacs@HIDDEN>
 <871rb6np5j.fsf@HIDDEN>
 <jwvczuqrm7s.fsf-monnier+emacs@HIDDEN>
 <a6e276cb03e0600b52bf@HIDDEN>
Date: Thu, 22 Apr 2021 09:56:39 -0400
In-Reply-To: <a6e276cb03e0600b52bf@HIDDEN> (Gregory Heytings's message
 of "Tue, 20 Apr 2021 19:00:29 +0000")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.029 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 45474
Cc: Dario Gjorgjevski <dario.gjorgjevski@HIDDEN>, 45474 <at> debbugs.gnu.org,
 Juri Linkov <juri@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> diff --git a/src/minibuf.c b/src/minibuf.c
> index c9831fd50f..6d4c2848f6 100644
> --- a/src/minibuf.c
> +++ b/src/minibuf.c
> @@ -862,6 +862,12 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
>    if (STRINGP (input_method) && !NILP (Ffboundp (Qactivate_input_method)))
>      call1 (Qactivate_input_method, input_method);
>  
> +  if (! EQ (Vminibuffer_local_completion_table, Qnil)) {
> +    Fmake_local_variable (Qminibuffer_completion_table);
> +    Fset (Qminibuffer_completion_table, Vminibuffer_local_completion_table);
> +    specbind (Qminibuffer_local_completion_table, Qnil);
> +  }
> +
>    run_hook (Qminibuffer_setup_hook);

I'm afraid this will suffer a similar problem to the one Juri
spotted in my code.


        Stefan





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45474; Package emacs. Full text available.

Message received at 45474 <at> debbugs.gnu.org:


Received: (at 45474) by debbugs.gnu.org; 22 Apr 2021 13:55:00 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Apr 22 09:55:00 2021
Received: from localhost ([127.0.0.1]:33237 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lZZnI-00019X-6V
	for submit <at> debbugs.gnu.org; Thu, 22 Apr 2021 09:55:00 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:3393)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1lZZnF-00019J-96
 for 45474 <at> debbugs.gnu.org; Thu, 22 Apr 2021 09:54:58 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 8C5BF100525;
 Thu, 22 Apr 2021 09:54:51 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 278101000C9;
 Thu, 22 Apr 2021 09:54:50 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1619099690;
 bh=Q/4r7sP78nRtV1v4qmJ8YRtDbCoQFXsZkLtKLUvIS5Y=;
 h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
 b=n/pAxY5fRekXe+eLbng5paKw63WsXvuI9tjuLFF/56ZID4cCt0ywuZh+BdEmdvaYZ
 vGCHd30JtesjDo1rn2kiVK9e23L5kDYa7ghRsKXpzcPB5KpE3IS6/Paau6UwX4C8WO
 mNXkMFGT1HTuyy2bjE5XHx8UPJRNRTG5/epsAtKbnXm4Boxr01A6zy2HZ2pheJRsJl
 NoDkrWJUMrqgF0LbSKfHzjAtw3Tt9Nt8dJFZLbq70F5uLhbrndfkXjABPW2XJGFyOz
 XZH1EWOaJOzsQpB7F02XfqkBH59EsPvQNOwQOH4nUP6bw6NFWxi3f6d8egwX/0zGfv
 6OFJMey/SZ98A==
Received: from alfajor (104-222-126-84.cpe.teksavvy.com [104.222.126.84])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id C22F31201C8;
 Thu, 22 Apr 2021 09:54:49 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Juri Linkov <juri@HIDDEN>
Subject: Re: bug#45474: Icomplete exhibiting in recursive minibuffer when it
 =?utf-8?Q?shouldn=E2=80=99t?=
Message-ID: <jwvsg3iig5h.fsf-monnier+emacs@HIDDEN>
References: <fv2zojtus7b0tz.fsf@HIDDEN> <3ed97a9c53e0a5d4fef8@HIDDEN>
 <87fszrz21d.fsf@HIDDEN>
 <3ed97a9c530093aca93d@HIDDEN>
 <7dee3f4235d331cab291@HIDDEN> <87r1jatd34.fsf@HIDDEN>
 <7dee3f423551aaf318cb@HIDDEN> <87im4kzlfm.fsf@HIDDEN>
 <1869622e16546eafd9df@HIDDEN>
 <jwvk0p04mbj.fsf-monnier+emacs@HIDDEN>
 <871rb6np5j.fsf@HIDDEN>
 <jwvczuqrm7s.fsf-monnier+emacs@HIDDEN>
 <87lf9cepqw.fsf@HIDDEN>
Date: Thu, 22 Apr 2021 09:54:48 -0400
In-Reply-To: <87lf9cepqw.fsf@HIDDEN> (Juri Linkov's message of "Tue, 
 20 Apr 2021 22:01:31 +0300")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.029 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 45474
Cc: Gregory Heytings <gregory@HIDDEN>,
 Dario Gjorgjevski <dario.gjorgjevski@HIDDEN>, 45474 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> I tested your patch and discovered that it fails when two nested
> minibuffers both use completion, e.g. C-x C-f C-h v raises the error:
>
>    Error in post-command-hook (icomplete-post-command-hook): (wrong-type-argument symbolp

Indeed, it's nasty:

- In the first step, we
  - let-bind (globally) m-c-table to read-file-name-internal
  - go to minibuf-1
  - make it buffer-local in minibuf-1
  - everything's dandy
- In the second step, things get ugly
  - we're in minibuf-1
  - we let-bind m-c-table to help--symbol-completion-table which
    only works buffer-locally in minibuf-1 (thus temporarily overriding
    the value set just before).
  - we go to minibuf-2 which still has no buffer-local setting so it
    sees the global value that's still read-file-name-internal (because
    of the very first part of the first step)
  - we make it buffer-local but to this wrong value

So in the end we get a wrong m-c-table in both buffers (the values are reversed!).


        Stefan





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45474; Package emacs. Full text available.

Message received at 45474 <at> debbugs.gnu.org:


Received: (at 45474) by debbugs.gnu.org; 20 Apr 2021 19:14:38 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Apr 20 15:14:38 2021
Received: from localhost ([127.0.0.1]:56029 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lYvpV-000676-T1
	for submit <at> debbugs.gnu.org; Tue, 20 Apr 2021 15:14:38 -0400
Received: from relay9-d.mail.gandi.net ([217.70.183.199]:51377)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <juri@HIDDEN>) id 1lYvpT-00066r-Eb
 for 45474 <at> debbugs.gnu.org; Tue, 20 Apr 2021 15:14:36 -0400
X-Originating-IP: 91.129.102.166
Received: from mail.gandi.net (m91-129-102-166.cust.tele2.ee [91.129.102.166])
 (Authenticated sender: juri@HIDDEN)
 by relay9-d.mail.gandi.net (Postfix) with ESMTPSA id 054B0FF806;
 Tue, 20 Apr 2021 19:14:26 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
Subject: Re: bug#45474: Icomplete exhibiting in recursive minibuffer when it
 =?utf-8?Q?shouldn=E2=80=99t?=
Organization: LINKOV.NET
References: <fv2zojtus7b0tz.fsf@HIDDEN> <3ed97a9c53e0a5d4fef8@HIDDEN>
 <87fszrz21d.fsf@HIDDEN>
 <3ed97a9c530093aca93d@HIDDEN>
 <7dee3f4235d331cab291@HIDDEN> <87r1jatd34.fsf@HIDDEN>
 <7dee3f423551aaf318cb@HIDDEN> <87im4kzlfm.fsf@HIDDEN>
 <1869622e16546eafd9df@HIDDEN>
 <jwvk0p04mbj.fsf-monnier+emacs@HIDDEN>
 <871rb6np5j.fsf@HIDDEN>
 <jwvczuqrm7s.fsf-monnier+emacs@HIDDEN>
Date: Tue, 20 Apr 2021 22:01:31 +0300
In-Reply-To: <jwvczuqrm7s.fsf-monnier+emacs@HIDDEN> (Stefan Monnier's message
 of "Mon, 19 Apr 2021 17:42:02 -0400")
Message-ID: <87lf9cepqw.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 45474
Cc: Gregory Heytings <gregory@HIDDEN>,
 Dario Gjorgjevski <dario.gjorgjevski@HIDDEN>, 45474 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

>> but then later you posted a different patch.  Anyway FWIW here is
>> a safer workable workaround that implements your first suggestion
>> and sets a new explicit buffer-local variable in completing minibuffers,
>> so modes that need to distinguish such minibuffers could check it.
>
> I combined your idea with that of Gregory for the patch below.
> It's far from perfect, but I think it strikes a good balance of
> simplicity, preserving compatibility, and moving in the right direction.
>
> WDYT?

I tested your patch and discovered that it fails when two nested
minibuffers both use completion, e.g. C-x C-f C-h v raises the error:

   Error in post-command-hook (icomplete-post-command-hook): (wrong-type-argument symbolp

The value of minibuffer-completion-table is 'read-file-name-internal'
in the C-x C-f minibuffer that is correct.  But the same value is also
in the nested C-h v minibuffer instead of the correct help--symbol-completion-table.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45474; Package emacs. Full text available.

Message received at 45474 <at> debbugs.gnu.org:


Received: (at 45474) by debbugs.gnu.org; 20 Apr 2021 19:00:35 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Apr 20 15:00:35 2021
Received: from localhost ([127.0.0.1]:56009 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lYvbu-0005mM-Oq
	for submit <at> debbugs.gnu.org; Tue, 20 Apr 2021 15:00:35 -0400
Received: from heytings.org ([95.142.160.155]:46264)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <gregory@HIDDEN>) id 1lYvbs-0005mC-9E
 for 45474 <at> debbugs.gnu.org; Tue, 20 Apr 2021 15:00:33 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org;
 s=20210101; t=1618945230;
 bh=vmEj3gT1mKxI0J1uaCl6X777HSkrgGsju/emUSASdEw=;
 h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From;
 b=wTFXQjkLTKdfgtMZOtnpLI5TJ2QnYE51U8FkYhMG06luzQb57Mj++FBge5LRhfyoP
 0L8yj1ffIgftH+Ncsq3JposwbcgslKwwpabmWHdGlP2GaXfy1DnWR8NhLN0sFIuE/Q
 fjZbQSb4gRfPXCH7wpi0FZ3idwpswjbwa5X4wg+TqWZvWSnP5GKygs+lerDFYIin8I
 zsIlsISGuf496weHif+EB4saeuvAjCtTWaUo0WRWUbK/xqH/+3mDwedVi/P2DgFPv2
 eC/MWcJWsHgxDCheHYGnll5+UpBekgv8gq0PuZtKm0apiGlx7FN2vCZ3qv4YThC9KM
 RZ0MELLR08NBA==
Date: Tue, 20 Apr 2021 19:00:29 +0000
From: Gregory Heytings <gregory@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
Subject: =?UTF-8?Q?Re=3A_bug#45474=3A_Icomplete_exhibiting_in_recursive?=
 =?UTF-8?Q?_minibuffer_when_it_shouldn=E2=80=99t?=
In-Reply-To: <jwvczuqrm7s.fsf-monnier+emacs@HIDDEN>
Message-ID: <a6e276cb03e0600b52bf@HIDDEN>
References: <fv2zojtus7b0tz.fsf@HIDDEN> <3ed97a9c53e0a5d4fef8@HIDDEN>
 <87fszrz21d.fsf@HIDDEN> <3ed97a9c530093aca93d@HIDDEN>
 <7dee3f4235d331cab291@HIDDEN> <87r1jatd34.fsf@HIDDEN>
 <7dee3f423551aaf318cb@HIDDEN>
 <87im4kzlfm.fsf@HIDDEN> <1869622e16546eafd9df@HIDDEN>
 <jwvk0p04mbj.fsf-monnier+emacs@HIDDEN> <871rb6np5j.fsf@HIDDEN>
 <jwvczuqrm7s.fsf-monnier+emacs@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="eydtYkrlVt"
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 45474
Cc: Dario Gjorgjevski <dario.gjorgjevski@HIDDEN>, 45474 <at> debbugs.gnu.org,
 Juri Linkov <juri@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)


--eydtYkrlVt
Content-Type: text/plain; format=flowed; charset=us-ascii


>> but then later you posted a different patch.  Anyway FWIW here is a 
>> safer workable workaround that implements your first suggestion and 
>> sets a new explicit buffer-local variable in completing minibuffers, so 
>> modes that need to distinguish such minibuffers could check it.
>
> I combined your idea with that of Gregory for the patch below. It's far 
> from perfect, but I think it strikes a good balance of simplicity, 
> preserving compatibility, and moving in the right direction.
>
> WDYT?
>

I really like the simplicity of that solution, but (you know me, there's 
always a but...) I do not see what the next step in that direction could 
be.  My fear is that package authors will be encouraged to use a similar 
duct tape in their code, and that making the behavior of 
read-from-minibuffer depend on a environment variable (or an additional 
parameter) will never happen.

I attach a patch which is, I believe, safe in the sense that it cannot 
break any package, and which creates a transition period after which 
minibuffer-completion-table will automatically become buffer-local upon 
entering the minibuffer.
--eydtYkrlVt
Content-Type: text/x-diff; name=Make-it-possible-to-disable-a-completion-backend-in-.patch
Content-Transfer-Encoding: base64
Content-ID: <a6e276cb0301e3c28ccd@HIDDEN>
Content-Description: 
Content-Disposition: attachment; filename=Make-it-possible-to-disable-a-completion-backend-in-.patch

RnJvbSA5M2EyNTdjZjUwZjEyMTBmOGIzMTQ4N2Y4OTJlYTZiZjhiYTQ1MGRi
IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQ0KRnJvbTogR3JlZ29yeSBIZXl0
aW5ncyA8Z3JlZ29yeUBoZXl0aW5ncy5vcmc+DQpEYXRlOiBUdWUsIDIwIEFw
ciAyMDIxIDE4OjQ2OjMzICswMDAwDQpTdWJqZWN0OiBbUEFUQ0hdIE1ha2Ug
aXQgcG9zc2libGUgdG8gZGlzYWJsZSBhIGNvbXBsZXRpb24gYmFja2VuZCBp
biByZWN1cnNpdmUNCiBtaW5pYnVmZmVycw0KDQotLS0NCiBsaXNwL21pbmli
dWZmZXIuZWwgfCAgMSArDQogbGlzcC9zdWJyLmVsICAgICAgIHwgMTMgKysr
KysrKysrKysrKw0KIHNyYy9mbnMuYyAgICAgICAgICB8ICA2ICsrKy0tLQ0K
IHNyYy9taW5pYnVmLmMgICAgICB8IDM3ICsrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKystLS0tLS0NCiA0IGZpbGVzIGNoYW5nZWQsIDQ4IGluc2Vy
dGlvbnMoKyksIDkgZGVsZXRpb25zKC0pDQoNCmRpZmYgLS1naXQgYS9saXNw
L21pbmlidWZmZXIuZWwgYi9saXNwL21pbmlidWZmZXIuZWwNCmluZGV4IGM5
MDBiMGQ3Y2UuLjIwMTAzYjUxOTEgMTAwNjQ0DQotLS0gYS9saXNwL21pbmli
dWZmZXIuZWwNCisrKyBiL2xpc3AvbWluaWJ1ZmZlci5lbA0KQEAgLTM4MjUs
NiArMzgyNSw3IEBAIGNvbXBsZXRpbmctcmVhZC1kZWZhdWx0DQogICAgICAg
ICAgICAgICAgICgxKyAoY2RyIGluaXRpYWwtaW5wdXQpKSkpKQ0KIA0KICAg
KGxldCogKChtaW5pYnVmZmVyLWNvbXBsZXRpb24tdGFibGUgY29sbGVjdGlv
bikNCisgICAgICAgICAobWluaWJ1ZmZlci1sb2NhbC1jb21wbGV0aW9uLXRh
YmxlIHQpDQogICAgICAgICAgKG1pbmlidWZmZXItY29tcGxldGlvbi1wcmVk
aWNhdGUgcHJlZGljYXRlKQ0KICAgICAgICAgIDs7IEZJWE1FOiBSZW1vdmUv
cmVuYW1lIHRoaXMgdmFyLCBzZWUgdGhlIG5leHQgb25lLg0KICAgICAgICAg
IChtaW5pYnVmZmVyLWNvbXBsZXRpb24tY29uZmlybSAodW5sZXNzIChlcSBy
ZXF1aXJlLW1hdGNoIHQpDQpkaWZmIC0tZ2l0IGEvbGlzcC9zdWJyLmVsIGIv
bGlzcC9zdWJyLmVsDQppbmRleCBjMmJlMjZhMTVmLi4yOGI0MmZhMzk4IDEw
MDY0NA0KLS0tIGEvbGlzcC9zdWJyLmVsDQorKysgYi9saXNwL3N1YnIuZWwN
CkBAIC0yNzkxLDYgKzI3OTEsMTkgQEAgcmVhZC1wYXNzd2QNCiAgICAgICAg
ICAgICAgIDs7IEFuZCBvZiBjb3Vyc2UsIGRvbid0IGtlZXAgdGhlIHNlbnNp
dGl2ZSBkYXRhIGFyb3VuZC4NCiAgICAgICAgICAgICAgIChlcmFzZS1idWZm
ZXIpKSkpKSkpKQ0KIA0KKyhkZWZtYWNybyByZWFkLWZyb20tbWluaWJ1ZmZl
ciAoJnJlc3QgYm9keSkNCisgICJSZWFkIGEgc3RyaW5nIGZyb20gdGhlIG1p
bmlidWZmZXIgd2l0aCBgaW50ZXJuYWwtcmVhZC1mcm9tLW1pbmlidWZmZXIn
Lg0KK1NlZSBgaW50ZXJuYWwtcmVhZC1mcm9tLW1pbmlidWZmZXInIGZvciBh
IGRlc2NyaXB0aW9uIG9mIHRoZSBhcmd1bWVudHMuDQorVGhpcyBtYWNybyBl
eGlzdHMgb25seSBpbiBFbWFjcyAyOCwgZm9yIHRoZSB0cmFuc2l0aW9uIHBl
cmlvZCBkdXJpbmcgd2hpY2gNCit0aGUgZGVmYXVsdCB2YWx1ZSBvZiBgbWlu
aWJ1ZmZlci1sb2NhbC1jb21wbGV0aW9uLXRhYmxlJyBpcyBuaWwsIGFuZCB3
aWxsIGJlDQorcmVtb3ZlZCBpbiBFbWFjcyAyOS4gIExpa2V3aXNlLCBgaW50
ZXJuYWwtcmVhZC1mcm9tLW1pbmlidWZmZXInIHdpbGwgYmUNCityZW1vdmVk
IGluIEVtYWNzIDI5LCBwbGVhc2UgZG8gbm90IHVzZSBpdCBkaXJlY3RseS4i
DQorICBgKGlmIG1pbmlidWZmZXItbG9jYWwtY29tcGxldGlvbi10YWJsZQ0K
KyAgICAgICAobGV0ICgobWluaWJ1ZmZlci1sb2NhbC1jb21wbGV0aW9uLXRh
YmxlIG1pbmlidWZmZXItY29tcGxldGlvbi10YWJsZSkpDQorICAgICAgICAg
KGxldCAoKG1pbmlidWZmZXItY29tcGxldGlvbi10YWJsZSBuaWwpKQ0KKyAg
ICAgICAgICAgKGludGVybmFsLXJlYWQtZnJvbS1taW5pYnVmZmVyICxAYm9k
eSkpKQ0KKyAgICAgKGludGVybmFsLXJlYWQtZnJvbS1taW5pYnVmZmVyICxA
Ym9keSkpKQ0KKw0KIChkZWZ2YXIgcmVhZC1udW1iZXItaGlzdG9yeSBuaWwN
CiAgICJUaGUgZGVmYXVsdCBoaXN0b3J5IGZvciB0aGUgYHJlYWQtbnVtYmVy
JyBmdW5jdGlvbi4iKQ0KIA0KZGlmZiAtLWdpdCBhL3NyYy9mbnMuYyBiL3Ny
Yy9mbnMuYw0KaW5kZXggMTc1ODE0OGZmMi4uZGI2Njc5YTg0NyAxMDA2NDQN
Ci0tLSBhL3NyYy9mbnMuYw0KKysrIGIvc3JjL2Zucy5jDQpAQCAtMjk4NSw5
ICsyOTg1LDkgQEAgREVGVU4gKCJ5ZXMtb3Itbm8tcCIsIEZ5ZXNfb3Jfbm9f
cCwgU3llc19vcl9ub19wLCAxLCAxLCAwLA0KIA0KICAgd2hpbGUgKDEpDQog
ICAgIHsNCi0gICAgICBhbnMgPSBGZG93bmNhc2UgKEZyZWFkX2Zyb21fbWlu
aWJ1ZmZlciAocHJvbXB0LCBRbmlsLCBRbmlsLCBRbmlsLA0KLQkJCQkJICAg
ICAgUXllc19vcl9ub19wX2hpc3RvcnksIFFuaWwsDQotCQkJCQkgICAgICBR
bmlsKSk7DQorICAgICAgYW5zID0gRmRvd25jYXNlIChGaW50ZXJuYWxfcmVh
ZF9mcm9tX21pbmlidWZmZXIgKHByb21wdCwgUW5pbCwgUW5pbCwgUW5pbCwN
CisJCQkJCQkgICAgICAgUXllc19vcl9ub19wX2hpc3RvcnksIFFuaWwsDQor
CQkJCQkJICAgICAgIFFuaWwpKTsNCiAgICAgICBpZiAoU0NIQVJTIChhbnMp
ID09IDMgJiYgIXN0cmNtcCAoU1NEQVRBIChhbnMpLCAieWVzIikpDQogCXJl
dHVybiB1bmJpbmRfdG8gKGNvdW50LCBRdCk7DQogICAgICAgaWYgKFNDSEFS
UyAoYW5zKSA9PSAyICYmICFzdHJjbXAgKFNTREFUQSAoYW5zKSwgIm5vIikp
DQpkaWZmIC0tZ2l0IGEvc3JjL21pbmlidWYuYyBiL3NyYy9taW5pYnVmLmMN
CmluZGV4IGM5ODMxZmQ1MGYuLjZkNGMyODQ4ZjYgMTAwNjQ0DQotLS0gYS9z
cmMvbWluaWJ1Zi5jDQorKysgYi9zcmMvbWluaWJ1Zi5jDQpAQCAtODYyLDYg
Kzg2MiwxMiBAQCByZWFkX21pbmlidWYgKExpc3BfT2JqZWN0IG1hcCwgTGlz
cF9PYmplY3QgaW5pdGlhbCwgTGlzcF9PYmplY3QgcHJvbXB0LA0KICAgaWYg
KFNUUklOR1AgKGlucHV0X21ldGhvZCkgJiYgIU5JTFAgKEZmYm91bmRwIChR
YWN0aXZhdGVfaW5wdXRfbWV0aG9kKSkpDQogICAgIGNhbGwxIChRYWN0aXZh
dGVfaW5wdXRfbWV0aG9kLCBpbnB1dF9tZXRob2QpOw0KIA0KKyAgaWYgKCEg
RVEgKFZtaW5pYnVmZmVyX2xvY2FsX2NvbXBsZXRpb25fdGFibGUsIFFuaWwp
KSB7DQorICAgIEZtYWtlX2xvY2FsX3ZhcmlhYmxlIChRbWluaWJ1ZmZlcl9j
b21wbGV0aW9uX3RhYmxlKTsNCisgICAgRnNldCAoUW1pbmlidWZmZXJfY29t
cGxldGlvbl90YWJsZSwgVm1pbmlidWZmZXJfbG9jYWxfY29tcGxldGlvbl90
YWJsZSk7DQorICAgIHNwZWNiaW5kIChRbWluaWJ1ZmZlcl9sb2NhbF9jb21w
bGV0aW9uX3RhYmxlLCBRbmlsKTsNCisgIH0NCisNCiAgIHJ1bl9ob29rIChR
bWluaWJ1ZmZlcl9zZXR1cF9ob29rKTsNCiANCiAgIC8qIERvbid0IGFsbG93
IHRoZSB1c2VyIHRvIHVuZG8gcGFzdCB0aGlzIHBvaW50LiAgKi8NCkBAIC0x
MjIzLDkgKzEyMjksMTYgQEAgYmFyZl9pZl9pbnRlcmFjdGlvbl9pbmhpYml0
ZWQgKHZvaWQpDQogICAgIHhzaWduYWwwIChRaW5oaWJpdGVkX2ludGVyYWN0
aW9uKTsNCiB9DQogDQotREVGVU4gKCJyZWFkLWZyb20tbWluaWJ1ZmZlciIs
IEZyZWFkX2Zyb21fbWluaWJ1ZmZlciwNCi0gICAgICAgU3JlYWRfZnJvbV9t
aW5pYnVmZmVyLCAxLCA3LCAwLA0KK0RFRlVOICgiaW50ZXJuYWwtcmVhZC1m
cm9tLW1pbmlidWZmZXIiLCBGaW50ZXJuYWxfcmVhZF9mcm9tX21pbmlidWZm
ZXIsDQorICAgICAgIFNpbnRlcm5hbF9yZWFkX2Zyb21fbWluaWJ1ZmZlciwg
MSwgNywgMCwNCiAgICAgICAgZG9jOiAvKiBSZWFkIGEgc3RyaW5nIGZyb20g
dGhlIG1pbmlidWZmZXIsIHByb21wdGluZyB3aXRoIHN0cmluZyBQUk9NUFQu
DQorDQorTm90ZTogRG8gbm90IHVzZSB0aGlzIGZ1bmN0aW9uIGRpcmVjdGx5
LCB1c2UgYHJlYWQtZnJvbS1taW5pYnVmZmVyJyBpbnN0ZWFkLA0KK3doaXRo
IHRoZSBhcmd1bWVudHMgZGVzY3JpYmVkIGJlbG93LiAgVGhlIGByZWFkLWZy
b20tbWluaWJ1ZmZlcicgbWFjcm8gZXhpc3RzDQorb25seSBpbiBFbWFjcyAy
OCBmb3IgdGhlIHRyYW5zaXRpb24gcGVyaW9kIGR1cmluZyB3aGljaCB0aGUg
ZGVmYXVsdCB2YWx1ZSBvZg0KK2BtaW5pYnVmZmVyLWxvY2FsLWNvbXBsZXRp
b24tdGFibGUnIGlzIG5pbCwgaXQgd2lsbCBiZSByZW1vdmVkIGluIEVtYWNz
IDI5LA0KK2FuZCBgaW50ZXJuYWwtcmVhZC1mcm9tLW1pbmlidWZmZXInIHdp
bGwgYmVjb21lIGByZWFkLWZyb20tbWluaWJ1ZmZlcicgYWdhaW4uDQorDQog
VGhlIG9wdGlvbmFsIHNlY29uZCBhcmcgSU5JVElBTC1DT05URU5UUyBpcyBh
biBvYnNvbGV0ZSBhbHRlcm5hdGl2ZSB0bw0KICAgREVGQVVMVC1WQUxVRS4g
IEl0IG5vcm1hbGx5IHNob3VsZCBiZSBuaWwgaW4gbmV3IGNvZGUsIGV4Y2Vw
dCB3aGVuDQogICBISVNUIGlzIGEgY29ucy4gIEl0IGlzIGRpc2N1c3NlZCBp
biBtb3JlIGRldGFpbCBiZWxvdy4NCkBAIC0xMzQ0LDkgKzEzNTcsOSBAQCBE
RUZVTiAoInJlYWQtc3RyaW5nIiwgRnJlYWRfc3RyaW5nLCBTcmVhZF9zdHJp
bmcsIDEsIDUsIDAsDQogICAgICBGSVhNRTogYG1pbmlidWZmZXItY29tcGxl
dGlvbi10YWJsZScgc2hvdWxkIGJlIGJ1ZmZlci1sb2NhbCBpbnN0ZWFkLiAg
Ki8NCiAgIHNwZWNiaW5kIChRbWluaWJ1ZmZlcl9jb21wbGV0aW9uX3RhYmxl
LCBRbmlsKTsNCiANCi0gIHZhbCA9IEZyZWFkX2Zyb21fbWluaWJ1ZmZlciAo
cHJvbXB0LCBpbml0aWFsX2lucHV0LCBRbmlsLA0KLQkJCSAgICAgICBRbmls
LCBoaXN0b3J5LCBkZWZhdWx0X3ZhbHVlLA0KLQkJCSAgICAgICBpbmhlcml0
X2lucHV0X21ldGhvZCk7DQorICB2YWwgPSBGaW50ZXJuYWxfcmVhZF9mcm9t
X21pbmlidWZmZXIgKHByb21wdCwgaW5pdGlhbF9pbnB1dCwgUW5pbCwNCisJ
CQkJICAgICAgICBRbmlsLCBoaXN0b3J5LCBkZWZhdWx0X3ZhbHVlLA0KKwkJ
CQkgICAgICAgIGluaGVyaXRfaW5wdXRfbWV0aG9kKTsNCiAgIGlmIChTVFJJ
TkdQICh2YWwpICYmIFNDSEFSUyAodmFsKSA9PSAwICYmICEgTklMUCAoZGVm
YXVsdF92YWx1ZSkpDQogICAgIHZhbCA9IENPTlNQIChkZWZhdWx0X3ZhbHVl
KSA/IFhDQVIgKGRlZmF1bHRfdmFsdWUpIDogZGVmYXVsdF92YWx1ZTsNCiAg
IHJldHVybiB1bmJpbmRfdG8gKGNvdW50LCB2YWwpOw0KQEAgLTIyOTcsNiAr
MjMxMCw3IEBAIHN5bXNfb2ZfbWluaWJ1ZiAodm9pZCkNCiAgIEZzZXQgKFFt
aW5pYnVmZmVyX2RlZmF1bHQsIFFuaWwpOw0KIA0KICAgREVGU1lNIChRbWlu
aWJ1ZmZlcl9jb21wbGV0aW9uX3RhYmxlLCAibWluaWJ1ZmZlci1jb21wbGV0
aW9uLXRhYmxlIik7DQorICBERUZTWU0gKFFtaW5pYnVmZmVyX2xvY2FsX2Nv
bXBsZXRpb25fdGFibGUsICJtaW5pYnVmZmVyLWxvY2FsLWNvbXBsZXRpb24t
dGFibGUiKTsNCiANCiAgIHN0YXRpY3BybyAoJmxhc3RfbWluaWJ1Zl9zdHJp
bmcpOw0KIA0KQEAgLTI0MDksNiArMjQyMywxNyBAQCBzeW1zX29mX21pbmli
dWYgKHZvaWQpDQogICBsYW1iZGEgLS0gcmV0dXJuIHQgaWYgU1RSSU5HIGlz
IGEgdmFsaWQgY29tcGxldGlvbiBhcyBpdCBzdGFuZHMuICAqLyk7DQogICBW
bWluaWJ1ZmZlcl9jb21wbGV0aW9uX3RhYmxlID0gUW5pbDsNCiANCisgIERF
RlZBUl9MSVNQICgibWluaWJ1ZmZlci1sb2NhbC1jb21wbGV0aW9uLXRhYmxl
IiwgVm1pbmlidWZmZXJfbG9jYWxfY29tcGxldGlvbl90YWJsZSwNCisJICAg
ICAgIGRvYzogLyogV2hldGhlciBgbWluaWJ1ZmZlci1jb21wbGV0aW9uLXRh
YmxlJyBzaG91bGQgYmVjb21lIGJ1ZmZlci1sb2NhbC4NCitUaGUgZGVmYXVs
dCBpcyBuaWwgZm9yIEVtYWNzIDI4LiAgU2V0dGluZyB0aGlzIHZhcmlhYmxl
IGluIEVtYWNzIDI5IHdpbGwgaGF2ZSBubyBlZmZlY3Q7DQordGhlIHZhbHVl
IHQgd2lsbCBiZSBhc3N1bWVkLg0KK1doZW4gdCwgYG1pbmlidWZmZXItY29t
cGxldGlvbi10YWJsZScgYmVjb21lcyBidWZmZXItbG9jYWwgdXBvbiBlbnRl
cmluZyB0aGUgbWluaWJ1ZmZlciwNCithbmQgaXMgbmlsIGluIHJlY3Vyc2l2
ZSBpbnZvY2F0aW9ucyBvZiB0aGUgbWluaWJ1ZmZlciwgdW5sZXNzIGl0IGhh
cyBiZWVuIGxldC1ib3VuZCB0bw0KK2EgdmFsdWUuDQorV2hlbiBuaWwsIGBt
aW5pYnVmZmVyLWNvbXBsZXRpb24tdGFibGUnIGlzIHNoYXJlZCBiZXR3ZWVu
IHRoZSByZWN1cnNpdmUgaW52b2NhdGlvbnMgb2YNCit0aGUgbWluaWJ1ZmZl
ciwgdW5sZXNzIGl0IGhhcyBiZWVuIGxldC1ib3VuZCB0byBhbm90aGVyIHZh
bHVlLiAgKi8pOw0KKyAgVm1pbmlidWZmZXJfbG9jYWxfY29tcGxldGlvbl90
YWJsZSA9IFFuaWw7DQorDQogICBERUZWQVJfTElTUCAoIm1pbmlidWZmZXIt
Y29tcGxldGlvbi1wcmVkaWNhdGUiLCBWbWluaWJ1ZmZlcl9jb21wbGV0aW9u
X3ByZWRpY2F0ZSwNCiAJICAgICAgIGRvYzogLyogV2l0aGluIGNhbGwgdG8g
YGNvbXBsZXRpbmctcmVhZCcsIHRoaXMgaG9sZHMgdGhlIFBSRURJQ0FURSBh
cmd1bWVudC4gICovKTsNCiAgIFZtaW5pYnVmZmVyX2NvbXBsZXRpb25fcHJl
ZGljYXRlID0gUW5pbDsNCkBAIC0yNDk2LDcgKzI1MjEsNyBAQCBzeW1zX29m
X21pbmlidWYgKHZvaWQpDQogDQogICBkZWZzdWJyICgmU2FjdGl2ZV9taW5p
YnVmZmVyX3dpbmRvdyk7DQogICBkZWZzdWJyICgmU3NldF9taW5pYnVmZmVy
X3dpbmRvdyk7DQotICBkZWZzdWJyICgmU3JlYWRfZnJvbV9taW5pYnVmZmVy
KTsNCisgIGRlZnN1YnIgKCZTaW50ZXJuYWxfcmVhZF9mcm9tX21pbmlidWZm
ZXIpOw0KICAgZGVmc3ViciAoJlNyZWFkX3N0cmluZyk7DQogICBkZWZzdWJy
ICgmU3JlYWRfY29tbWFuZCk7DQogICBkZWZzdWJyICgmU3JlYWRfdmFyaWFi
bGUpOw0KLS0gDQoyLjMwLjINCg0K

--eydtYkrlVt--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45474; Package emacs. Full text available.

Message received at 45474 <at> debbugs.gnu.org:


Received: (at 45474) by debbugs.gnu.org; 19 Apr 2021 21:42:20 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Apr 19 17:42:20 2021
Received: from localhost ([127.0.0.1]:52278 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lYbeq-0000Gv-O3
	for submit <at> debbugs.gnu.org; Mon, 19 Apr 2021 17:42:20 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:23205)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1lYbel-0000Ge-GE
 for 45474 <at> debbugs.gnu.org; Mon, 19 Apr 2021 17:42:15 -0400
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
 by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id B07BD4411AD;
 Mon, 19 Apr 2021 17:42:05 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 176F1441195;
 Mon, 19 Apr 2021 17:42:04 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1618868524;
 bh=vK9nAHNSc1xFAJq2+//FuLCcQZ8HOE7DctNx2IRE+bc=;
 h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
 b=D5UOyUI2xmge9kKT3gKcTj726LhPdu51F0gvmio38cjHL3LKNyElyucTDAmVW5j/I
 SQACNiyb1zK3LCLdSJzpTFha7Aia6mDQzpttt7rnp681ybgprqgiMyerNzsBS6bktM
 Csg+1qUzeSE+Sp67jBGksIpVxDKjCSUC1NkeDMAWn5uxMUE7/oDrdWNrstDxxiCpKX
 iuhag8yu8y5L1qLonuZEHsQ40lS4gm5F0GXSk2wU359ukpzM15WFMTes9vAuf0bmOt
 OvoSKCrcSVzZPaRfFMmJdH7/SdXCEEj33x2KNbTUyZYpat3T2HmS5+tQWnXVveIp3L
 DZElXanpcUJoQ==
Received: from alfajor (104-222-126-84.cpe.teksavvy.com [104.222.126.84])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id C4205120257;
 Mon, 19 Apr 2021 17:42:03 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Juri Linkov <juri@HIDDEN>
Subject: Re: bug#45474: Icomplete exhibiting in recursive minibuffer when it
 =?utf-8?Q?shouldn=E2=80=99t?=
Message-ID: <jwvczuqrm7s.fsf-monnier+emacs@HIDDEN>
References: <fv2zojtus7b0tz.fsf@HIDDEN> <3ed97a9c53e0a5d4fef8@HIDDEN>
 <87fszrz21d.fsf@HIDDEN>
 <3ed97a9c530093aca93d@HIDDEN>
 <7dee3f4235d331cab291@HIDDEN> <87r1jatd34.fsf@HIDDEN>
 <7dee3f423551aaf318cb@HIDDEN> <87im4kzlfm.fsf@HIDDEN>
 <1869622e16546eafd9df@HIDDEN>
 <jwvk0p04mbj.fsf-monnier+emacs@HIDDEN>
 <871rb6np5j.fsf@HIDDEN>
Date: Mon, 19 Apr 2021 17:42:02 -0400
In-Reply-To: <871rb6np5j.fsf@HIDDEN> (Juri Linkov's message of "Mon, 
 19 Apr 2021 21:16:18 +0300")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.100 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 45474
Cc: Gregory Heytings <gregory@HIDDEN>,
 Dario Gjorgjevski <dario.gjorgjevski@HIDDEN>, 45474 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> but then later you posted a different patch.  Anyway FWIW here is
> a safer workable workaround that implements your first suggestion
> and sets a new explicit buffer-local variable in completing minibuffers,
> so modes that need to distinguish such minibuffers could check it.

I combined your idea with that of Gregory for the patch below.
It's far from perfect, but I think it strikes a good balance of
simplicity, preserving compatibility, and moving in the right direction.

WDYT?

> Maybe this minibuffer-with-setup-hook could be moved even to
> 'completing-read'?

Because of the fundamentally broken&messy way
`minibuffer-with-setup-hook` works, it's best to keep it as close as
possible to the call to `read-from-minibuffer`, IMO.


        Stefan


diff --git a/lisp/icomplete.el b/lisp/icomplete.el
index 91bbb600136..df9c5241234 100644
--- a/lisp/icomplete.el
+++ b/lisp/icomplete.el
@@ -400,7 +400,9 @@ icomplete-mode
     (add-hook 'minibuffer-setup-hook #'icomplete-minibuffer-setup)))
 
 (defun icomplete--completion-table ()
-  (if (window-minibuffer-p) minibuffer-completion-table
+  (if (window-minibuffer-p)
+      (if (local-variable-p 'minibuffer-completion-table)
+          minibuffer-completion-table)
     (or (nth 2 completion-in-region--data)
 	(message "In %S (w=%S): %S"
 		 (current-buffer) (selected-window) (window-minibuffer-p)))))
diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index c19f9096290..04fbd092c27 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -3857,8 +3857,11 @@ completing-read-default
                     ;; in minibuffer-local-filename-completion-map can
                     ;; override bindings in base-keymap.
                     base-keymap)))
-         (result (read-from-minibuffer prompt initial-input keymap
-                                       nil hist def inherit-input-method)))
+         (result
+          (minibuffer-with-setup-hook
+              (lambda () (make-local-variable 'minibuffer-completion-table))
+            (read-from-minibuffer prompt initial-input keymap
+                                  nil hist def inherit-input-method))))
     (when (and (equal result "") def)
       (setq result (if (consp def) (car def) def)))
     result))





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45474; Package emacs. Full text available.

Message received at 45474 <at> debbugs.gnu.org:


Received: (at 45474) by debbugs.gnu.org; 19 Apr 2021 20:20:08 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Apr 19 16:20:08 2021
Received: from localhost ([127.0.0.1]:52189 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lYaNM-0002Rr-7S
	for submit <at> debbugs.gnu.org; Mon, 19 Apr 2021 16:20:08 -0400
Received: from heytings.org ([95.142.160.155]:45196)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <gregory@HIDDEN>) id 1lYaNK-0002Rj-Gt
 for 45474 <at> debbugs.gnu.org; Mon, 19 Apr 2021 16:20:07 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org;
 s=20210101; t=1618863605;
 bh=3aEOpxStni9qh/6LdvHJxaSHX5uKwJ1igLbkVpg034c=;
 h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From;
 b=bn5NEInB4TnggyyzjocmlIxjMPLntL+1yT3xIwuJrwRX7iiuQo9PGzFRVwOGH4glA
 7TOWH4L6Wk3j2ouYLI2ibtBqAd443MTfG2fPgU+Xdbzh9pC4o/lJjnhn4cZ6/JXQdE
 QbU0dxTiGo6lw8XnzB08PTywMnYfJ5MNug0UKYHP7akDbThDo3PRCeYoE51pdEFGKX
 9FdXcqDfShpoFYPYKzguCPfIjkzoTVKbDYzA/zXYp2mdLXN9FoJDXGTpRQrTWOSweP
 PHCKBuAXqC4AUVBXWdsd+ktngrt1im1Vo8eMzTi7Y0siKLIjaIHnDe4nCeEXBMsRmf
 arQ5dkYy+BDog==
Date: Mon, 19 Apr 2021 20:20:04 +0000
From: Gregory Heytings <gregory@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
Subject: =?UTF-8?Q?Re=3A_bug#45474=3A_Icomplete_exhibiting_in_recursive?=
 =?UTF-8?Q?_minibuffer_when_it_shouldn=E2=80=99t?=
In-Reply-To: <jwvfszmuvvu.fsf-monnier+emacs@HIDDEN>
Message-ID: <bb7c6f5fc9dc791a3102@HIDDEN>
References: <fv2zojtus7b0tz.fsf@HIDDEN> <3ed97a9c53e0a5d4fef8@HIDDEN>
 <87fszrz21d.fsf@HIDDEN> <3ed97a9c530093aca93d@HIDDEN>
 <7dee3f4235d331cab291@HIDDEN> <87r1jatd34.fsf@HIDDEN>
 <7dee3f423551aaf318cb@HIDDEN>
 <87im4kzlfm.fsf@HIDDEN> <1869622e16546eafd9df@HIDDEN>
 <jwvk0p04mbj.fsf-monnier+emacs@HIDDEN> <1869622e16dc36c3f2fd@HIDDEN>
 <jwvfszn3by1.fsf-monnier+emacs@HIDDEN> <c40b32b1f8c49b47c52d@HIDDEN>
 <jwvtuo3xejk.fsf-monnier+emacs@HIDDEN>
 <bb7c6f5fc9d3118de394@HIDDEN> <jwvfszmuvvu.fsf-monnier+emacs@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset=us-ascii
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 45474
Cc: Dario Gjorgjevski <dario.gjorgjevski@HIDDEN>, 45474 <at> debbugs.gnu.org,
 Juri Linkov <juri@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)


>
> I think we should:
>
> - Do something along the lines of the whitelist approach, as the "long 
> term" solution.
>
> - Add to it some "short term" heuristic (e.g. using something like the 
> "equal keymap" or the minibuffer depth) that keeps it working for 
> ivy-read and friends, maybe emitting a warning along the way (and with a 
> clean way to silence this warning when it's a false positive) so we can 
> remove the heuristic in Emacs-30.
>
> WDYT?
>

I've been thinking about this, and now have another potential solution in 
mind, which I'm not sure it is feasible.  The assumption of this idea is 
that the present problem is an instance of a more general problem, i.e. 
that similar problems will arise for other functions in the future.  The 
general idea is to make the following possible, when a function foo needs 
to be changed to depend on some variable bar or to accept an additional 
argument baz:

Emacs N:

- rename the function foo to internal-foo

- add a macro foo which (a) either calls internal-foo after setting bar or 
baz to a default value that make internal-foo behave as foo in Emacs N - 
1, or (b) calls internal-foo directly (i.e. assuming that bar or baz have 
been set appropriately)

The macro would (and here I'm not sure it is feasible) expand to (a) for 
external packages that have not yet been upgraded, and to (b) for those 
who have been upgraded and for Emacs core.  The question is: is it 
possible to have a predicate function to distinguish those two cases?

Emacs N + 1:

- remove the macro foo

- rename the function internal-foo back to foo

To illustrate the above with the present problem, read-from-minibuffer 
would depend on the value of completing-read-from-minibuffer, which would 
default to nil for Emacs core (and packages that have been upgraded) and 
would be let-bound to t in completing-read-default, and would default to t 
for external packages (that have not yet been upgraded).

>> Yes, I understood this, but the effect of let-binding the var and make 
>> it buffer-local after the minibuffer has been created but before the 
>> minibuffer-setup-hook is executed is the same.  Or am I missing 
>> something?
>
> [ Note: I consider this part of the discussion as not directly relevant 
> to bug#45474.  ]
>

Indeed ;-)  I guess the above idea is also a bit far from bug#45474...

>
> Oh, so `read-from-minibuffer` receives it as an "implicit argument" vet 
> dynamically scoped let-binding and then sets it buffer locally?
>

Exactly.  It receives an argument through its environment instead of an 
explicit one.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45474; Package emacs. Full text available.

Message received at 45474 <at> debbugs.gnu.org:


Received: (at 45474) by debbugs.gnu.org; 19 Apr 2021 18:22:34 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Apr 19 14:22:34 2021
Received: from localhost ([127.0.0.1]:52038 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lYYXZ-0007xU-LB
	for submit <at> debbugs.gnu.org; Mon, 19 Apr 2021 14:22:34 -0400
Received: from relay6-d.mail.gandi.net ([217.70.183.198]:56037)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <juri@HIDDEN>) id 1lYYXX-0007wv-Si
 for 45474 <at> debbugs.gnu.org; Mon, 19 Apr 2021 14:22:32 -0400
X-Originating-IP: 91.129.102.166
Received: from mail.gandi.net (m91-129-102-166.cust.tele2.ee [91.129.102.166])
 (Authenticated sender: juri@HIDDEN)
 by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id C2DDFC000A;
 Mon, 19 Apr 2021 18:22:23 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
Subject: Re: bug#45474: Icomplete exhibiting in recursive minibuffer when it
 =?utf-8?Q?shouldn=E2=80=99t?=
Organization: LINKOV.NET
References: <fv2zojtus7b0tz.fsf@HIDDEN> <3ed97a9c53e0a5d4fef8@HIDDEN>
 <87fszrz21d.fsf@HIDDEN>
 <3ed97a9c530093aca93d@HIDDEN>
 <7dee3f4235d331cab291@HIDDEN> <87r1jatd34.fsf@HIDDEN>
 <7dee3f423551aaf318cb@HIDDEN> <87im4kzlfm.fsf@HIDDEN>
 <1869622e16546eafd9df@HIDDEN>
 <jwvk0p04mbj.fsf-monnier+emacs@HIDDEN>
Date: Mon, 19 Apr 2021 21:16:18 +0300
In-Reply-To: <jwvk0p04mbj.fsf-monnier+emacs@HIDDEN> (Stefan Monnier's message
 of "Sat, 17 Apr 2021 17:58:31 -0400")
Message-ID: <871rb6np5j.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 45474
Cc: Gregory Heytings <gregory@HIDDEN>,
 Dario Gjorgjevski <dario.gjorgjevski@HIDDEN>, 45474 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

--=-=-=
Content-Type: text/plain

> A quick&dirty workaround for now would be for `completing-read` to set
> some var alongside `minibuffer-completion-table` which indicates *which*
> minibuffer this is for (e.g. some minibuffer-depth information).
> This way `read-from-minibuffer` could distinguish
> a `minibuffer-completion-table` passed for the current invocation from
> one passed for the outer invocation and could hence temporarily rebind
> `minibuffer-completion-table` to nil.

This patch is how I thought your suggestion could be implemented,
but then later you posted a different patch.  Anyway FWIW here is
a safer workable workaround that implements your first suggestion
and sets a new explicit buffer-local variable in completing minibuffers,
so modes that need to distinguish such minibuffers could check it.
Maybe this minibuffer-with-setup-hook could be moved even to
'completing-read'?



--=-=-=
Content-Type: text/x-diff
Content-Disposition: inline; filename=completing-minibuffer.patch

diff --git a/lisp/icomplete.el b/lisp/icomplete.el
index 91bbb60013..543e451c5d 100644
--- a/lisp/icomplete.el
+++ b/lisp/icomplete.el
@@ -400,7 +400,7 @@ icomplete-mode
     (add-hook 'minibuffer-setup-hook #'icomplete-minibuffer-setup)))
 
 (defun icomplete--completion-table ()
-  (if (window-minibuffer-p) minibuffer-completion-table
+  (if (window-minibuffer-p) (and completing-minibuffer minibuffer-completion-table)
     (or (nth 2 completion-in-region--data)
 	(message "In %S (w=%S): %S"
 		 (current-buffer) (selected-window) (window-minibuffer-p)))))
diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index a0247d1fba..3ceb67733d 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -3826,6 +3826,8 @@ completing-read-function
   "The function called by `completing-read' to do its work.
 It should accept the same arguments as `completing-read'.")
 
+(defvar completing-minibuffer nil)
+
 (defun completing-read-default (prompt collection &optional predicate
                                        require-match initial-input
                                        hist def inherit-input-method)
@@ -3839,6 +3841,9 @@ completing-read-default
                 ;; `read-from-minibuffer' uses 1-based index.
                 (1+ (cdr initial-input)))))
 
+  (minibuffer-with-setup-hook
+      (lambda ()
+        (setq-local completing-minibuffer t))
     (let* ((minibuffer-completion-table collection)
            (minibuffer-completion-predicate predicate)
            ;; FIXME: Remove/rename this var, see the next one.
@@ -3862,7 +3867,7 @@ completing-read-default
                                          nil hist def inherit-input-method)))
       (when (and (equal result "") def)
         (setq result (if (consp def) (car def) def)))
-    result))
+      result)))
 
 ;; Miscellaneous
 

--=-=-=--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45474; Package emacs. Full text available.

Message received at 45474 <at> debbugs.gnu.org:


Received: (at 45474) by debbugs.gnu.org; 19 Apr 2021 15:58:16 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Apr 19 11:58:16 2021
Received: from localhost ([127.0.0.1]:51812 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lYWHw-0001xa-DQ
	for submit <at> debbugs.gnu.org; Mon, 19 Apr 2021 11:58:16 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:32137)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1lYWHu-0001xJ-5t
 for 45474 <at> debbugs.gnu.org; Mon, 19 Apr 2021 11:58:15 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 065231002F2;
 Mon, 19 Apr 2021 11:58:02 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 7E5861000D0;
 Mon, 19 Apr 2021 11:58:00 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1618847880;
 bh=njcG1WtMp6noiw2sXQN58IZGnpbv7Wf+hk8kL5T6hHw=;
 h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
 b=crvHLPxS1Cgqp9/aJKOUpVkUWBG7pMoDMxH9q/9Kv1Ikj8lPB1Hu3zJnpaGO3QJ0A
 vUpn53OTqsV7wuB+Jk4ht/kDietaeO2Flk+9gnfss55NWkVOzBLzMNu3R+doQJAaer
 YL0U90fwFvRmhGvPyOeA8ly6gfDNyHT/pvnPzq8IAl6Jrwv+DmgUqYeXs9w9NuToPA
 96csv8cICbkgVUMFyt8SuGCINU6RcsKUgTRJr6sNqeM0agiSnSZibjcv1qN8dn13Cy
 2zF03o7noevLvYFwb+5tXNT9o/8NWwE/aZP21g6+YoWbdQO9M5oZ6RcArIchSQrMqy
 iBk68eyx1oPWA==
Received: from alfajor (104-222-126-84.cpe.teksavvy.com [104.222.126.84])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 34E8E12026E;
 Mon, 19 Apr 2021 11:58:00 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Gregory Heytings <gregory@HIDDEN>
Subject: Re: bug#45474: Icomplete exhibiting in recursive minibuffer when it
 =?utf-8?Q?shouldn=E2=80=99t?=
Message-ID: <jwvfszmuvvu.fsf-monnier+emacs@HIDDEN>
References: <fv2zojtus7b0tz.fsf@HIDDEN> <3ed97a9c53e0a5d4fef8@HIDDEN>
 <87fszrz21d.fsf@HIDDEN>
 <3ed97a9c530093aca93d@HIDDEN>
 <7dee3f4235d331cab291@HIDDEN> <87r1jatd34.fsf@HIDDEN>
 <7dee3f423551aaf318cb@HIDDEN> <87im4kzlfm.fsf@HIDDEN>
 <1869622e16546eafd9df@HIDDEN>
 <jwvk0p04mbj.fsf-monnier+emacs@HIDDEN>
 <1869622e16dc36c3f2fd@HIDDEN>
 <jwvfszn3by1.fsf-monnier+emacs@HIDDEN>
 <c40b32b1f8c49b47c52d@HIDDEN>
 <jwvtuo3xejk.fsf-monnier+emacs@HIDDEN>
 <bb7c6f5fc9d3118de394@HIDDEN>
Date: Mon, 19 Apr 2021 11:57:59 -0400
In-Reply-To: <bb7c6f5fc9d3118de394@HIDDEN> (Gregory Heytings's message
 of "Mon, 19 Apr 2021 12:14:18 +0000")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.024 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 45474
Cc: Dario Gjorgjevski <dario.gjorgjevski@HIDDEN>, 45474 <at> debbugs.gnu.org,
 Juri Linkov <juri@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> There are 76 calls to read-from-minibuffer on ELPA.  AFAICS, the only call
> that uses minibuffer-completion-table is the one iside ivy-read.
[...]
> There are 903 calls to read-from-minibuffer on MELPA.  AFAICS, only
> a handful of them (yatex, gams-mode, python-django, magit) use
> minibuffer-completion-table.  The case of Magit is interesting: it solves
> the current problem by defining two functions,
> magit-completing-read-multiple that let-binds minibuffer-completion-table to
> the appropriate value, and magit-read-string that let-binds
> minibuffer-completion-table to nil.

[ Thanks for the footwork.  ]

So the whitelist approach we're considering would break and few cases
like `ivy-read`, and `magit-completing-read-multiple` and would fix the
corner case misbehavior in hundred of other calls.

The blacklist approach would instead not break anything but would
require adding extra code to a few hundred places to fix those corner
case misbehaviors.

I'm starting to feel that neither option is very attractive.
I think we should:
- Do something along the lines of the whitelist approach, as the
  "long term" solution.
- Add to it some "short term" heuristic (e.g. using something like the
  "equal keymap" or the minibuffer depth) that keeps it working for
  ivy-read and friends, maybe emitting a warning along the way (and with
  a clean way to silence this warning when it's a false positive) so we
  can remove the heuristic in Emacs-30.

WDYT?

>> No, I meant that instead of using let-binding to set the var, we'd use
>> `setq-local`. This requires the code to run from within the minibuffer,
>> contrary to the current situation where the let-binding takes place
>> outside of the minibuffer.
> Yes, I understood this, but the effect of let-binding the var and make it
> buffer-local after the minibuffer has been created but before the
> minibuffer-setup-hook is executed is the same.  Or am I missing something?

[ Note: I consider this part of the discussion as not directly relevant to
  bug#45474.  ]

Oh, so `read-from-minibuffer` receives it as an "implicit argument" vet
dynamically scoped let-binding and then sets it buffer locally?

That sounds like a potentially good halfway point, so code which
(incorrectly) uses `minibuffer-completion-table` from non-mini buffers
will still usually get the right table (e.g. when there's only one
minibuffer active).

> If not, this would solve the problem without breaking anything (as the
> global value of minibuffer-completion-table would not change).

Exactly.


        Stefan





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45474; Package emacs. Full text available.

Message received at 45474 <at> debbugs.gnu.org:


Received: (at 45474) by debbugs.gnu.org; 19 Apr 2021 12:14:22 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Apr 19 08:14:22 2021
Received: from localhost ([127.0.0.1]:48619 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lYSnF-0003IB-MG
	for submit <at> debbugs.gnu.org; Mon, 19 Apr 2021 08:14:21 -0400
Received: from heytings.org ([95.142.160.155]:44512)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <gregory@HIDDEN>) id 1lYSnE-0003I2-7o
 for 45474 <at> debbugs.gnu.org; Mon, 19 Apr 2021 08:14:20 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org;
 s=20210101; t=1618834459;
 bh=yf4PCr0R7pXtNHFc4uY1pdJjhDY9Dqpe4y1DutYxGLY=;
 h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From;
 b=klCv5jGzEH+2iCpJheYj5tK0VH31CTTjWY4MZZjjFEVzJtuPRjKbvda5nnBYhR82q
 4WLl5LZicN+hHNGZ5AVXWg0SR/uWWmp1GNJTuD+7+hDbRgRZobxMTj+rPs5LG16dTP
 zZRAurDPPdh1/mc22qlzOdlnlDxHZqb3zJwsrSY4RM4GVZEuLCzPwQsMOUpXs071F0
 ya2lUcfHvYPTGmjF29xNkS/y8IHVfbehdNlSznMoobBsms+0wr0sy77HOebubzsVDo
 NYIAnUsYDM94z4HBrXk0jhx6pgDAmhuAWEOfgZOpXul7Ri+SrnaGwCi358JzHdhwxn
 KcLIuF8nIdd3Q==
Date: Mon, 19 Apr 2021 12:14:18 +0000
From: Gregory Heytings <gregory@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
Subject: =?UTF-8?Q?Re=3A_bug#45474=3A_Icomplete_exhibiting_in_recursive?=
 =?UTF-8?Q?_minibuffer_when_it_shouldn=E2=80=99t?=
In-Reply-To: <jwvtuo3xejk.fsf-monnier+emacs@HIDDEN>
Message-ID: <bb7c6f5fc9d3118de394@HIDDEN>
References: <fv2zojtus7b0tz.fsf@HIDDEN> <3ed97a9c53e0a5d4fef8@HIDDEN>
 <87fszrz21d.fsf@HIDDEN> <3ed97a9c530093aca93d@HIDDEN>
 <7dee3f4235d331cab291@HIDDEN> <87r1jatd34.fsf@HIDDEN>
 <7dee3f423551aaf318cb@HIDDEN>
 <87im4kzlfm.fsf@HIDDEN> <1869622e16546eafd9df@HIDDEN>
 <jwvk0p04mbj.fsf-monnier+emacs@HIDDEN> <1869622e16dc36c3f2fd@HIDDEN>
 <jwvfszn3by1.fsf-monnier+emacs@HIDDEN> <c40b32b1f8c49b47c52d@HIDDEN>
 <jwvtuo3xejk.fsf-monnier+emacs@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset=us-ascii
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 45474
Cc: Dario Gjorgjevski <dario.gjorgjevski@HIDDEN>, 45474 <at> debbugs.gnu.org,
 Juri Linkov <juri@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)


>> It would be possible to use whitelisting instead by renaming the 
>> current read-from-minibuffer to internal-read-from-minibuffer, which 
>> would be wrapped in a macro read-from-minibuffer.
>
> Indeed.  I think we need more data in order to figure out which of the 
> two options breaks less/more code out there.
>

Here is some (hopefully useful) data:

There are 213 calls to read-from-minibuffer in Emacs core.  AFAICS, the 
only call that uses minibuffer-completion-table is the one inside 
completing-read-default.  There's another one inside ido-read-internal, 
but it doesn't seem to use minibuffer-completion-table, AFAIU it replaces 
completing-read with its own processing in ido-exhibit.

There are 76 calls to read-from-minibuffer on ELPA.  AFAICS, the only call 
that uses minibuffer-completion-table is the one iside ivy-read.

There are 903 calls to read-from-minibuffer on MELPA.  AFAICS, only a 
handful of them (yatex, gams-mode, python-django, magit) use 
minibuffer-completion-table.  The case of Magit is interesting: it solves 
the current problem by defining two functions, 
magit-completing-read-multiple that let-binds minibuffer-completion-table 
to the appropriate value, and magit-read-string that let-binds 
minibuffer-completion-table to nil.

>
> I was working under the assumption that the only calls to 
> `read-from-minibuffer` which need the minibuffer to have a 
> `minibuffer-completion-table` are those coming from 
> `completing-read-default` (in which case the whitelisting is the better 
> approach since it requires a change only in `completing-read-default`), 
> but the fact that there's a `completing-read-function` is a strong hint 
> that this assumption is probably wrong.
>

I believe your assumption is mostly correct.  There are apparently only 
very few occurrences of read-from-minibuffer that use 
minibuffer-completion-table, and my understanding is that those who set 
completing-read-function to another value do not use 
minibuffer-completion-table anymore.

>> The change would be transparent, except for those places (e.g. 
>> completing-read-default) where what we actually want is to use 
>> internal-read-from-minibuffer.  But this change would be slightly more 
>> invasive than what follows.
>
> Actually, probably not very much, and it would be a lot cleaner.
>

I agree.

>>> 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
>>
>> I'm not sure I fully understand why this is necessary, but is 
>> "Fmake_variable_buffer_local (Qminibuffer_completion_table);" just 
>> after "if ... specbind (Qminibuffer_completion_table, Qnil);" not 
>> enough for this?
>
> No, I meant that instead of using let-binding to set the var, we'd use 
> `setq-local`. This requires the code to run from within the minibuffer, 
> contrary to the current situation where the let-binding takes place 
> outside of the minibuffer.
>

Yes, I understood this, but the effect of let-binding the var and make it 
buffer-local after the minibuffer has been created but before the 
minibuffer-setup-hook is executed is the same.  Or am I missing something? 
If not, this would solve the problem without breaking anything (as the 
global value of minibuffer-completion-table would not change).




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45474; Package emacs. Full text available.

Message received at 45474 <at> debbugs.gnu.org:


Received: (at 45474) by debbugs.gnu.org; 19 Apr 2021 01:26:26 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Apr 18 21:26:25 2021
Received: from localhost ([127.0.0.1]:48069 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lYIgD-0001Vm-C9
	for submit <at> debbugs.gnu.org; Sun, 18 Apr 2021 21:26:25 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:24426)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1lYIgB-0001VY-1g
 for 45474 <at> debbugs.gnu.org; Sun, 18 Apr 2021 21:26:23 -0400
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
 by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 570D6441827;
 Sun, 18 Apr 2021 21:26:17 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 10CCA44172F;
 Sun, 18 Apr 2021 21:26:15 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1618795575;
 bh=58urrBtfJ2FbyT/iGQ3bs/lXV4DRe8uPGkUXY4J24E4=;
 h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
 b=hTnEqLKORX0P+i2WaG2Q3QeKEn0k0MNqMSDDOcKGGlHecISQSzXo6Tsz2dTflXa/f
 pCH2e6YVWNeR7zYF1Fi6ILxCsdQM1ghvYaVFYV2uDbAvWAsQF6TM90sAPmSwGXlQlQ
 /j2fPwZR+l8Nd/QVAflLcCCegHzIGGIOb/0EAHa6hHgZd32js3AlKX05etBR0fqRls
 yPKeaEF68yT2ZOb1X9WImMx3rcMZuKUtYXWUW7s++SvbEjRiViyuO7S/M58XXdg3BC
 k2Oc4zPXzUS/sX55QlePFCY5BefIGDyKgI9etYR6KZ7/EmX6iR5dOk7J07Ta1OUcSL
 XSgMCuueB5P2Q==
Received: from alfajor (104-222-126-84.cpe.teksavvy.com [104.222.126.84])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id CD79712017B;
 Sun, 18 Apr 2021 21:26:13 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Gregory Heytings <gregory@HIDDEN>
Subject: Re: bug#45474: Icomplete exhibiting in recursive minibuffer when it
 =?utf-8?Q?shouldn=E2=80=99t?=
Message-ID: <jwvtuo3xejk.fsf-monnier+emacs@HIDDEN>
References: <fv2zojtus7b0tz.fsf@HIDDEN> <3ed97a9c53e0a5d4fef8@HIDDEN>
 <87fszrz21d.fsf@HIDDEN>
 <3ed97a9c530093aca93d@HIDDEN>
 <7dee3f4235d331cab291@HIDDEN> <87r1jatd34.fsf@HIDDEN>
 <7dee3f423551aaf318cb@HIDDEN> <87im4kzlfm.fsf@HIDDEN>
 <1869622e16546eafd9df@HIDDEN>
 <jwvk0p04mbj.fsf-monnier+emacs@HIDDEN>
 <1869622e16dc36c3f2fd@HIDDEN>
 <jwvfszn3by1.fsf-monnier+emacs@HIDDEN>
 <c40b32b1f8c49b47c52d@HIDDEN>
Date: Sun, 18 Apr 2021 21:26:13 -0400
In-Reply-To: <c40b32b1f8c49b47c52d@HIDDEN> (Gregory Heytings's message
 of "Sun, 18 Apr 2021 22:23:46 +0000")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.098 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 45474
Cc: Dario Gjorgjevski <dario.gjorgjevski@HIDDEN>, 45474 <at> debbugs.gnu.org,
 Juri Linkov <juri@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

>>> 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).
> It would be possible to use whitelisting instead by renaming the current
> read-from-minibuffer to internal-read-from-minibuffer, which would be
> wrapped in a macro read-from-minibuffer.

Indeed.  I think we need more data in order to figure out which of the
two options breaks less/more code out there.

I was working under the assumption that the only calls to
`read-from-minibuffer` which need the minibuffer to have
a `minibuffer-completion-table` are those coming from
`completing-read-default` (in which case the whitelisting is the better
approach since it requires a change only in `completing-read-default`),
but the fact that there's a `completing-read-function` is a strong hint
that this assumption is probably wrong.

> The change would be transparent, except for those places
> (e.g. completing-read-default) where what we actually want is to use
> internal-read-from-minibuffer.  But this change would be slightly more
> invasive than what follows.

Actually, probably not very much, and it would be a lot cleaner.

>>> 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.
> Thanks.  Somehow I feel that using the keymap to decide whether the
> completion table should be used isn't safe enough, it's possible (at least
> in theory) that a minibuffer with a certain keymap uses completion tables
> and another one using the same keymap does not.

I agree that it's possible in theory, but I think in practice it's
extremely unlikely ;-)

> ISTM that it's safer (and more explicit) to use the current minibuffer
> depth for that purpose; see attached patch.

Actually, I think this is not safe: I suspect that minibuffer uses that
take place from the debugger (or the Edebugger) right between the
let-binding of `minibuffer-completion-map` and the call to
`read-from-minibuffer` would all have just the same depth as the one
that will apply to the call to `read-from-minibuffer` so they would
"misfire".

If we add "recursive edit depth" to the mix, we may get something that
is somewhat reliable, tho.

Still, sounds terribly hackish/hideous.  Not much better than my "equal
keymap" heuristic.  Your above `internal-read-from-minibuffer` would be
miles better, I think.

>> 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
> I'm not sure I fully understand why this is necessary, but is
> "Fmake_variable_buffer_local (Qminibuffer_completion_table);" just after "if
> ... specbind (Qminibuffer_completion_table, Qnil);" not enough for this?

No, I meant that instead of using let-binding to set the var, we'd use
`setq-local`.  This requires the code to run from within the minibuffer,
contrary to the current situation where the let-binding takes place
outside of the minibuffer.

IOW, the idea is that we'd pass to `read-from-minibuffer` some kind of
setup function.

But this is a much deeper change, and I expect it would break some
completion UIs which currently use `minibuffer-completion-table` (and
related variables) from other buffers than the minibuffer (e.g. from
*Completions*).
I wrote "would", but I do think such a change should happen at
some point.


        Stefan





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45474; Package emacs. Full text available.

Message received at 45474 <at> debbugs.gnu.org:


Received: (at 45474) by debbugs.gnu.org; 18 Apr 2021 23:46:12 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Apr 18 19:46:12 2021
Received: from localhost ([127.0.0.1]:48029 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lYH7E-0007aQ-Gl
	for submit <at> debbugs.gnu.org; Sun, 18 Apr 2021 19:46:12 -0400
Received: from aserp2120.oracle.com ([141.146.126.78]:35548)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <drew.adams@HIDDEN>) id 1lYH7C-0007aB-5l
 for 45474 <at> debbugs.gnu.org; Sun, 18 Apr 2021 19:46:10 -0400
Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1])
 by aserp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 13INihd6016730;
 Sun, 18 Apr 2021 23:46:04 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com;
 h=from : to : cc :
 subject : date : message-id : references : in-reply-to : content-type :
 content-transfer-encoding : mime-version; s=corp-2020-01-29;
 bh=iR3XUZnftYU3kLBHMz3dq96w295GKDYIWeI/JUOdCSI=;
 b=tQjkZSP4G+QNprSXwXBt+g0o1UsIOboD/qBmw0F69CgKDEBAnhuLm+WwOu1qMLhdUkY2
 pbzWBSwDKjL/KucdKCs7x7448ouplIdmshILre0JbQ0f5SswfPbq21h02MwwXOqoDAaf
 uRzPHKGsMm+C/PFfuvH7Rkv5FEEwhaMPV6opkzLxkfrF4QLA/DUPvA8p99f4rWx608Q9
 0Sg6MXEgyTcW0W5Bl+nD3Suf4M5YrN17hm3Bq61UMLrTLJSoBj/4M7b+TPk8L39TfR9k
 Lcln5O1IUraiWol7+KrKDxIy3D8kOwoecY9GGIdrHbEbdTdFxd75J9hFHYkYXJSSo4aN Xg== 
Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70])
 by aserp2120.oracle.com with ESMTP id 37yqmn9un6-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Sun, 18 Apr 2021 23:46:04 +0000
Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1])
 by aserp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 13INk05e177787;
 Sun, 18 Apr 2021 23:46:03 GMT
Received: from nam11-co1-obe.outbound.protection.outlook.com
 (mail-co1nam11lp2175.outbound.protection.outlook.com [104.47.56.175])
 by aserp3020.oracle.com with ESMTP id 3809jx22j9-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Sun, 18 Apr 2021 23:46:03 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=L9XXwXk8l68jUDjLp0g8LvY25Z8QDIHCRpjvD+tvOe+EcxzA9mL72YLcFpgZCMTKhby9hDi/i6EUet1nyww9AUF0mxuvc7Aj9epTLVu3lwIk7sJmohKXJIbpTNACC+We6YTMSUvxMQO0cm0MO3r0rGnVf6UiHtb7E9JOvTBtu74OCT92evkzK65AWuY+DBB911o3cUY3xRF+MCm5RTmR65rCEY04Qbk/EjTQD0aA87Z+JRHWX12Zy85mYfhCGF7fQTKKROO30Zxs9bZ1YDGRnYCQdkVm9jf9S9La6QSqKubUZe2w6Y4Q0W6epQCWqcpruGgnDcuThVEBFHTT4pWE3w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; 
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=iR3XUZnftYU3kLBHMz3dq96w295GKDYIWeI/JUOdCSI=;
 b=U2llUxvYf4/X8/MDea7E5MEUMabwQlEIipKzv/6j7kTTVNiH5bC0L8rlYRBOQBLNHHyDc2lFWaYLfi8YMINpcJtm/B1BSTErpzNaaVt+djqzFtOQm76AybXFZwxmqE/dakfspZ0LunerNyJDbkf0dEdBxdh3FvMLaqU5Fcwp3qEpHYLe8jPpWJJnWxiNgtlGB1+FX8vYsQ+QowkkwjkHyv2XV/kJNtMubzFjD9WBGJbZO75PNLJCIX5tCxqqh8exmvJggCdL+3NssbzKYGvMEj8LyfPc+NKjedXXlKL3yaUxoI4wvqlVE/Sw1kR613RGLaHpodUw2cE0h7DRk/bPog==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com;
 dkim=pass header.d=oracle.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=iR3XUZnftYU3kLBHMz3dq96w295GKDYIWeI/JUOdCSI=;
 b=jC6YnsxkDDWprYxipgBj2KjDs/qb2TUObHNNWIOWnbyaBlTFbSneKZPeequ6rnZpilzkFq4K3Ob64J4jQs3BEiHWlUMiln2w7jIRNqefSvYI5Qh4I7oGqTNfS5pVq6Ip57q9J1mzD8D04aVI0e8otGtOj9kaBtO8Yj8ZXpynU/w=
Received: from SA2PR10MB4474.namprd10.prod.outlook.com (2603:10b6:806:11b::15)
 by SN6PR10MB3069.namprd10.prod.outlook.com (2603:10b6:805:cd::22)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4042.19; Sun, 18 Apr
 2021 23:46:01 +0000
Received: from SA2PR10MB4474.namprd10.prod.outlook.com
 ([fe80::2109:9725:fd4a:6494]) by SA2PR10MB4474.namprd10.prod.outlook.com
 ([fe80::2109:9725:fd4a:6494%6]) with mapi id 15.20.4042.024; Sun, 18 Apr 2021
 23:46:01 +0000
From: Drew Adams <drew.adams@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
Subject: =?Windows-1252?Q?RE:_[External]_:_bug#45474:_Icomplete_exhibiting_in_recu?=
 =?Windows-1252?Q?rsive_minibuffer_when_it_shouldn=92t?=
Thread-Topic: =?Windows-1252?Q?[External]_:_bug#45474:_Icomplete_exhibiting_in_recursiv?=
 =?Windows-1252?Q?e_minibuffer_when_it_shouldn=92t?=
Thread-Index: AQHXNJTwjNsNYUy92k2mg9Y1jtG0TKq652SQ
Date: Sun, 18 Apr 2021 23:46:01 +0000
Message-ID: <SA2PR10MB44740E0461ACB6E20CCACD5DF34A9@HIDDEN>
References: <fv2zojtus7b0tz.fsf@HIDDEN> <3ed97a9c53e0a5d4fef8@HIDDEN>
 <87fszrz21d.fsf@HIDDEN>
 <3ed97a9c530093aca93d@HIDDEN>
 <7dee3f4235d331cab291@HIDDEN> <87r1jatd34.fsf@HIDDEN>
 <7dee3f423551aaf318cb@HIDDEN> <87im4kzlfm.fsf@HIDDEN>
 <1869622e16546eafd9df@HIDDEN>	<jwvk0p04mbj.fsf-monnier+emacs@HIDDEN>
 <SA2PR10MB44745ED4108357EC76AA7A6AF34B9@HIDDEN>
 <jwv35vo4539.fsf-monnier+emacs@HIDDEN>
 <SA2PR10MB4474642A71D8488D46B4870BF34A9@HIDDEN>
 <jwvr1j82nba.fsf-monnier+emacs@HIDDEN>
 <SA2PR10MB447493ACD79B3A73FB19D76EF34A9@HIDDEN>
 <jwvh7k31lws.fsf-monnier+emacs@HIDDEN>
 <SA2PR10MB44743A94DEACF3BC1D51E499F34A9@HIDDEN>
 <jwvo8ebz56c.fsf-monnier+emacs@HIDDEN>
In-Reply-To: <jwvo8ebz56c.fsf-monnier+emacs@HIDDEN>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: iro.umontreal.ca; dkim=none (message not signed)
 header.d=none;iro.umontreal.ca; dmarc=none action=none
 header.from=oracle.com;
x-originating-ip: [73.170.83.28]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: bdc37197-269a-467b-91e2-08d902c41f4e
x-ms-traffictypediagnostic: SN6PR10MB3069:
x-microsoft-antispam-prvs: <SN6PR10MB306936E7077C95E486002B75F34A9@HIDDEN>
x-ms-oob-tlc-oobclassifiers: OLM:7691;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 5UoUjmq0xxWMLYS7zPXfqoX9jFlK1GHl5Ez8HglsQDT7LE2V1BpIHJF/pUxIBFrPXGGW9vALLj36wGAgaE8BDNnyNATje/yy6To/cu5Q8Y+nS/jq4BlywstZCfYf8OBj5meeTQDCDA9MywpoDllxI0VxZSu1lLiHPJCi8OxFH7XKNNxSnCNGMgRiosTdD2uQ1LVmMyDuCpr4K9KtoUcXF8gq41/PP5y74S8PqEPfXtGVH7VENO3JrLOSrFe59zoQ0FIzdO1uRueBQXgnBqLUsiNaHNOhG+Phed6K/0FwdHgEVhgQjeAOx7L4OZo+3X+zgvFBGPxWcol66FNIfYcCbaMtyKfHgSxh8Kokz7aT3vBsFXU8kKshjVu8G2IGVXNiK/uQmGMgHRWGnUHgp6mGeViKqzYqfpjPQ7dDjsriREk/NkmCD58yuevbz/LYCwyyl2KTuK1CWiJqSk8z/OU+TVGPvc7fcJBdau6pi2sOh183K/VqvLbyPEyt+mdbxvlz+nxKn80VqeH6eZW6T1KeJVWDphwLayfeLF/T0zciqdlGk8EhlTzaoLKUzLO6j1bEsIN1h/BnVqFcgwexJVeQFJqTr2CGCpSDeUEo0+A3YVQ=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;
 IPV:NLI; SFV:NSPM; H:SA2PR10MB4474.namprd10.prod.outlook.com; PTR:; CAT:NONE;
 SFS:(39860400002)(366004)(136003)(346002)(396003)(376002)(55016002)(38100700002)(122000001)(9686003)(2906002)(66946007)(66476007)(66556008)(64756008)(66446008)(33656002)(86362001)(76116006)(5660300002)(52536014)(6506007)(71200400001)(316002)(296002)(6916009)(8936002)(478600001)(44832011)(186003)(7696005)(4326008)(54906003)(26005);
 DIR:OUT; SFP:1101; 
x-ms-exchange-antispam-messagedata: =?Windows-1252?Q?meFfxUYeSmUtDSIoLurcTw7D9cjRkbGqCebytAih/spodTl3JYRzVp5K?=
 =?Windows-1252?Q?/ebSSBb4QVod+Nj9q2pJv37hjijp+6aDnQL2nKBTjTXVTcrHQiITxgEu?=
 =?Windows-1252?Q?YiUn6ggBNShQrPEbNa0O1Hik/Z12O+kviC4rxr7m1ZlzAzBYjYbJYBKn?=
 =?Windows-1252?Q?I9n3dvwilFJqRbJQuMG2e5kmjO82yjsR/huEof2w6nh+CinG/7XAluO5?=
 =?Windows-1252?Q?98GaX+qGRQ6Sz6aQbcRpOyWy/JYTK5VDd1k7KIaXXiVMhs9J24uy8D9G?=
 =?Windows-1252?Q?DXrkVSHvAjCHcQ2/biU/8nV5DX2a0q9vOvFAm85A+WuZ3jpdjvAOX8Up?=
 =?Windows-1252?Q?0ZNmgUgmS232x3zJDMvKWV522txRhZbsCg6N+Q2nj6xQY5DuAO0jDYWS?=
 =?Windows-1252?Q?wU7Y0SDM+43SXXfsISo46b9gxRNmP0uaFimK8hTH5DPqCEhiTtslCOB3?=
 =?Windows-1252?Q?GNHxbW/igYYc/QthaiyNNrzoITPu9PLIzE1CrLR+jIAd22h4K93Qu6fv?=
 =?Windows-1252?Q?hRIhmG0vinhgn4O0cmARJXW6LdAHZmIR3hWuxU7YSDLsgEBf80HFWqci?=
 =?Windows-1252?Q?rb29mB0Dz+p7IUYVfxcm3KqPAiQ/rwrl+ZN568KKIOcNdKv2wHes0Nte?=
 =?Windows-1252?Q?3shk0m1miSfmgzqgA9ey8pCt6I3qcUdFwRfyZx++2nqgHqR7Be1PkbE4?=
 =?Windows-1252?Q?KKn95I9qBPVrJNn2uXCUqgxMhEVL+LUQDuEoE9h7xb1F7jJK9wfStmcp?=
 =?Windows-1252?Q?tPQcFXPf+rJyncD2iAlz4wGtmr7uLzV0T8XMPcwZ04Qs+mBNT2oBx/Xw?=
 =?Windows-1252?Q?tgYTrYpF5WieIHpU87rwOVMIDSRmrEoKzZpEvHd77/NXeaa2Va73WT1F?=
 =?Windows-1252?Q?PAqvg5x+raOdXHfy+GAWoz8rfjoc3M023F6QtbmwKeuZomvLyDGIKXOM?=
 =?Windows-1252?Q?zKYgUuopIj8V5wmXx88OU/meuoWkY1C52O9q3AIS6s1AuWEm1n76PSQV?=
 =?Windows-1252?Q?WoUmyLmvpyTZ0Njt/TH43hGHN4EJ9/Zt2p2Ops4EWRnrOLQ3O0uCxPR0?=
 =?Windows-1252?Q?1PM/NIodHgCFcKCqLglMXLUEhtjNOyAGeRv9w0DWh7c7NKS/IeIIlCEf?=
 =?Windows-1252?Q?c45hYym13tQzwkf25mPp5SyGc3swWbQjX08hlp9DAVpG/UOkBwpQ4Dx4?=
 =?Windows-1252?Q?9hdalC9UYAexwGe1soPhwn6Emn9+edPVgMf4gsLOIbFPhFxbPru5/RnZ?=
 =?Windows-1252?Q?fXDD+j+Zooeq4tB+3kJm+hixEsVs34n4CbEvRcMXbGjp1mJ0MHvoOL1t?=
 =?Windows-1252?Q?np921+XWs6li3m85za6nTa4PounqRIZDbt/g0SXzaYVC58Gpur2gThV0?=
 =?Windows-1252?Q?IRueRe3y9qHThggaO2Rv2/8TX7K7XbV14ya8f2dxoFTCf38WGWnJDoS1?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SA2PR10MB4474.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: bdc37197-269a-467b-91e2-08d902c41f4e
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Apr 2021 23:46:01.1077 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 9md1bLJUZBLpUkJ4ihcGo5/sM9MTRFyf3+k1qZkSwJW6YgSO3fd4ou15ql2lyAVm7+PTK6UJx33Rjcz1Ilg+JA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR10MB3069
X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9958
 signatures=668683
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0
 bulkscore=0 malwarescore=0
 suspectscore=0 phishscore=0 spamscore=0 mlxlogscore=999 mlxscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104060000
 definitions=main-2104180171
X-Proofpoint-ORIG-GUID: E-C9zwqM-4xiqdIcXgfAOEkDvBbEvuwq
X-Proofpoint-GUID: E-C9zwqM-4xiqdIcXgfAOEkDvBbEvuwq
X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9958
 signatures=668683
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0
 mlxscore=0 adultscore=0
 impostorscore=0 spamscore=0 malwarescore=0 clxscore=1015
 lowpriorityscore=0 priorityscore=1501 suspectscore=0 mlxlogscore=999
 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2104060000 definitions=main-2104180171
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 45474
Cc: Gregory Heytings <gregory@HIDDEN>, Juri Linkov <juri@HIDDEN>,
 Dario Gjorgjevski <dario.gjorgjevski@HIDDEN>,
 "45474 <at> debbugs.gnu.org" <45474 <at> debbugs.gnu.org>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> your objection reduces to just "you're proposing a
> change and I have no idea what you're talking about
> but I'll object anyway because by definition a change
> may break something".  You're right, but it doesn't
> bring anything to the discussion.

That's insulting, and not a helpful or fair
characterization.  I didn't object simply because
a change, any change, may break something.  I think
you know that.

I said clearly, at the outset:

   Apologies for not following this thread, and so
   possibly misunderstanding what you mean there.

That's a polite way of asking for clarification of
what you wrote there.

I said what I guessed you meant, and I said that if
that's what you meant then it's problematic for me.

It was clear that I understood you to be proposing
non-dynamic scoping for `minibuffer-completion-table',
based on your saying:

   instead of being "set" by dynamic scoping

And it was clear that I wasn't sure ("possibly
misunderstanding") what you meant by that phrase.

If you didn't mean that, and it was clear to you
that I was misunderstanding you, you could have
simply said so, and clarified what you meant.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45474; Package emacs. Full text available.

Message received at 45474 <at> debbugs.gnu.org:


Received: (at 45474) by debbugs.gnu.org; 18 Apr 2021 22:23:49 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Apr 18 18:23:49 2021
Received: from localhost ([127.0.0.1]:48012 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lYFpV-0005bL-Gg
	for submit <at> debbugs.gnu.org; Sun, 18 Apr 2021 18:23:49 -0400
Received: from heytings.org ([95.142.160.155]:43902)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <gregory@HIDDEN>) id 1lYFpT-0005bC-Us
 for 45474 <at> debbugs.gnu.org; Sun, 18 Apr 2021 18:23:48 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org;
 s=20210101; t=1618784626;
 bh=geBGSZWLrgRjUrr1QK8JWUFCsbbFbRSKARPy2mvNfpo=;
 h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From;
 b=WcUFgB8USWA3NdsILws9d+OL6YuSYeWZI579SLbGMa+lBgrxjvCXZ7CqbxnK1Zqb1
 18EwVgWwLTQBOPe9NpZP3gaMNa5PgKnrvWYliS5IiBHLElHnAc3H/bUU/dhb07oZJA
 c8XWDuWTEc5BrztR9cpAD4dBBykHP6l9dwjIa2phMF0WSdPvZ8oZllRed90kwzjcKV
 apaU8QaL7gcn6BTXirQLwJSIM3vj8G5KcoKKKfrnkbeAh2yJKaz9qoc46HWBPc7bJf
 z08vYoyBsWAnjuaj628iq8STtT4RPEkLjO9jkjNIEHHI9NuxLrLn0VkOI04ak9ndec
 q/y/valskX+5w==
Date: Sun, 18 Apr 2021 22:23:46 +0000
From: Gregory Heytings <gregory@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
Subject: =?UTF-8?Q?Re=3A_bug#45474=3A_Icomplete_exhibiting_in_recursive?=
 =?UTF-8?Q?_minibuffer_when_it_shouldn=E2=80=99t?=
In-Reply-To: <jwvfszn3by1.fsf-monnier+emacs@HIDDEN>
Message-ID: <c40b32b1f8c49b47c52d@HIDDEN>
References: <fv2zojtus7b0tz.fsf@HIDDEN> <3ed97a9c53e0a5d4fef8@HIDDEN>
 <87fszrz21d.fsf@HIDDEN> <3ed97a9c530093aca93d@HIDDEN>
 <7dee3f4235d331cab291@HIDDEN> <87r1jatd34.fsf@HIDDEN>
 <7dee3f423551aaf318cb@HIDDEN>
 <87im4kzlfm.fsf@HIDDEN> <1869622e16546eafd9df@HIDDEN>
 <jwvk0p04mbj.fsf-monnier+emacs@HIDDEN> <1869622e16dc36c3f2fd@HIDDEN>
 <jwvfszn3by1.fsf-monnier+emacs@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="ocGwpE4YpI"
Content-ID: <c40b32b1f8291afe2009@HIDDEN>
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 45474
Cc: Dario Gjorgjevski <dario.gjorgjevski@HIDDEN>, 45474 <at> debbugs.gnu.org,
 Juri Linkov <juri@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)


--ocGwpE4YpI
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-ID: <c40b32b1f8d799eef5a3@HIDDEN>


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

It would be possible to use whitelisting instead by renaming the current 
read-from-minibuffer to internal-read-from-minibuffer, which would be 
wrapped in a macro read-from-minibuffer.  The change would be transparent, 
except for those places (e.g. completing-read-default) where what we 
actually want is to use internal-read-from-minibuffer.  But this change 
would be slightly more invasive than what follows.

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

Thanks.  Somehow I feel that using the keymap to decide whether the 
completion table should be used isn't safe enough, it's possible (at least 
in theory) that a minibuffer with a certain keymap uses completion tables 
and another one using the same keymap does not.  ISTM that it's safer (and 
more explicit) to use the current minibuffer depth for that purpose; see 
attached patch.

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

I'm not sure I fully understand why this is necessary, but is 
"Fmake_variable_buffer_local (Qminibuffer_completion_table);" just after 
"if ... specbind (Qminibuffer_completion_table, Qnil);" not enough for 
this?
--ocGwpE4YpI
Content-Type: text/x-diff; name=Make-it-possible-to-disable-completion-in-recursive-.patch; charset=us-ascii
Content-Transfer-Encoding: base64
Content-ID: <c40b32b1f86731be4c80@HIDDEN>
Content-Description: 
Content-Disposition: attachment; filename=Make-it-possible-to-disable-completion-in-recursive-.patch

RnJvbSA0NjU0YzUyNTFjYWI2NzAzZTRkY2Q5NGVjYWE5MDBiYjk3MGJiNTg5
IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQ0KRnJvbTogR3JlZ29yeSBIZXl0
aW5ncyA8Z3JlZ29yeUBoZXl0aW5ncy5vcmc+DQpEYXRlOiBTdW4sIDE4IEFw
ciAyMDIxIDIyOjE1OjA4ICswMDAwDQpTdWJqZWN0OiBbUEFUQ0hdIE1ha2Ug
aXQgcG9zc2libGUgdG8gZGlzYWJsZSBjb21wbGV0aW9uIGluIHJlY3Vyc2l2
ZQ0KIG1pbmlidWZmZXJzDQoNCi0tLQ0KIGxpc3AvbWluaWJ1ZmZlci5lbCB8
ICAxICsNCiBzcmMvbWluaWJ1Zi5jICAgICAgfCAxNSArKysrKysrKystLS0t
LS0NCiAyIGZpbGVzIGNoYW5nZWQsIDEwIGluc2VydGlvbnMoKyksIDYgZGVs
ZXRpb25zKC0pDQoNCmRpZmYgLS1naXQgYS9saXNwL21pbmlidWZmZXIuZWwg
Yi9saXNwL21pbmlidWZmZXIuZWwNCmluZGV4IGM5MDBiMGQ3Y2UuLjk5MWVk
OWRjOTMgMTAwNjQ0DQotLS0gYS9saXNwL21pbmlidWZmZXIuZWwNCisrKyBi
L2xpc3AvbWluaWJ1ZmZlci5lbA0KQEAgLTM4MjUsNiArMzgyNSw3IEBAIGNv
bXBsZXRpbmctcmVhZC1kZWZhdWx0DQogICAgICAgICAgICAgICAgICgxKyAo
Y2RyIGluaXRpYWwtaW5wdXQpKSkpKQ0KIA0KICAgKGxldCogKChtaW5pYnVm
ZmVyLWNvbXBsZXRpb24tdGFibGUgY29sbGVjdGlvbikNCisgICAgICAgICAo
bWluaWJ1ZmZlci0tZGVwdGgtZm9yLWNvbXBsZXRpb24tdGFibGUgKG1pbmli
dWZmZXItZGVwdGgpKQ0KICAgICAgICAgIChtaW5pYnVmZmVyLWNvbXBsZXRp
b24tcHJlZGljYXRlIHByZWRpY2F0ZSkNCiAgICAgICAgICA7OyBGSVhNRTog
UmVtb3ZlL3JlbmFtZSB0aGlzIHZhciwgc2VlIHRoZSBuZXh0IG9uZS4NCiAg
ICAgICAgICAobWluaWJ1ZmZlci1jb21wbGV0aW9uLWNvbmZpcm0gKHVubGVz
cyAoZXEgcmVxdWlyZS1tYXRjaCB0KQ0KZGlmZiAtLWdpdCBhL3NyYy9taW5p
YnVmLmMgYi9zcmMvbWluaWJ1Zi5jDQppbmRleCBjOTgzMWZkNTBmLi43Nzk5
MmUxZmVhIDEwMDY0NA0KLS0tIGEvc3JjL21pbmlidWYuYw0KKysrIGIvc3Jj
L21pbmlidWYuYw0KQEAgLTU1OSw2ICs1NTksOSBAQCByZWFkX21pbmlidWYg
KExpc3BfT2JqZWN0IG1hcCwgTGlzcF9PYmplY3QgaW5pdGlhbCwgTGlzcF9P
YmplY3QgcHJvbXB0LA0KICAgc3BlY2JpbmQgKFFtaW5pYnVmZmVyX2RlZmF1
bHQsIGRlZmFsdCk7DQogICBzcGVjYmluZCAoUWluaGliaXRfcmVhZF9vbmx5
LCBRbmlsKTsNCiANCisgIGlmICghRVEgKFZtaW5pYnVmZmVyX19kZXB0aF9m
b3JfY29tcGxldGlvbl90YWJsZSwgbWFrZV9maXhudW0gKG1pbmlidWZfbGV2
ZWwpKSkNCisgICAgc3BlY2JpbmQgKFFtaW5pYnVmZmVyX2NvbXBsZXRpb25f
dGFibGUsIFFuaWwpOw0KKw0KICAgLyogSWYgVm1pbmlidWZmZXJfY29tcGxl
dGluZ19maWxlX25hbWUgaXMgYGxhbWJkYScgb24gZW50cnksIGl0IHdhcyB0
DQogICAgICBpbiBwcmV2aW91cyByZWN1cnNpdmUgbWluaWJ1ZmZlciwgYnV0
IHdhcyBub3Qgc2V0IGV4cGxpY2l0bHkNCiAgICAgIHRvIHQgZm9yIHRoaXMg
aW52b2NhdGlvbiwgc28gc2V0IGl0IHRvIG5pbCBpbiB0aGlzIG1pbmlidWZm
ZXIuDQpAQCAtMTMzOCwxMiArMTM0MSw2IEBAIERFRlVOICgicmVhZC1zdHJp
bmciLCBGcmVhZF9zdHJpbmcsIFNyZWFkX3N0cmluZywgMSwgNSwgMCwNCiAg
IExpc3BfT2JqZWN0IHZhbDsNCiAgIHB0cmRpZmZfdCBjb3VudCA9IFNQRUNQ
RExfSU5ERVggKCk7DQogDQotICAvKiBKdXN0IGluIGNhc2Ugd2UncmUgaW4g
YSByZWN1cnNpdmUgbWluaWJ1ZmZlciwgbWFrZSBpdCBjbGVhciB0aGF0IHRo
ZQ0KLSAgICAgcHJldmlvdXMgbWluaWJ1ZmZlcidzIGNvbXBsZXRpb24gdGFi
bGUgZG9lcyBub3QgYXBwbHkgdG8gdGhlIG5ldw0KLSAgICAgbWluaWJ1ZmZl
ci4NCi0gICAgIEZJWE1FOiBgbWluaWJ1ZmZlci1jb21wbGV0aW9uLXRhYmxl
JyBzaG91bGQgYmUgYnVmZmVyLWxvY2FsIGluc3RlYWQuICAqLw0KLSAgc3Bl
Y2JpbmQgKFFtaW5pYnVmZmVyX2NvbXBsZXRpb25fdGFibGUsIFFuaWwpOw0K
LQ0KICAgdmFsID0gRnJlYWRfZnJvbV9taW5pYnVmZmVyIChwcm9tcHQsIGlu
aXRpYWxfaW5wdXQsIFFuaWwsDQogCQkJICAgICAgIFFuaWwsIGhpc3Rvcnks
IGRlZmF1bHRfdmFsdWUsDQogCQkJICAgICAgIGluaGVyaXRfaW5wdXRfbWV0
aG9kKTsNCkBAIC0yMzk0LDYgKzIzOTEsMTIgQEAgc3ltc19vZl9taW5pYnVm
ICh2b2lkKQ0KIHZhcmlhYmxlIGlzIG5vbi1uaWwuICovKTsNCiAgIGVuYWJs
ZV9yZWN1cnNpdmVfbWluaWJ1ZmZlcnMgPSAwOw0KIA0KKyAgREVGVkFSX0xJ
U1AgKCJtaW5pYnVmZmVyLS1kZXB0aC1mb3ItY29tcGxldGlvbi10YWJsZSIs
IFZtaW5pYnVmZmVyX19kZXB0aF9mb3JfY29tcGxldGlvbl90YWJsZSwNCisg
ICAgICAgICAgICAgICBkb2M6IC8qIE1pbmlidWZmZXIgZGVwdGggdXNlZCB0
b2dldGhlciB3aXRoIGBtaW5pYnVmZmVyLWNvbXBsZXRpb24tdGFibGUnLg0K
K2ByZWFkLWZyb20tbWluaWJ1ZmZlcicgY29tcGFyZXMgaXQgd2l0aCB0aGUg
Y3VycmVudCBtaW5pYnVmZmVyIGRlcHRoIHRvDQorZGV0ZXJtaW5lIGlmIHRo
ZSBjb21wbGV0aW9uIHRhYmxlIHdhcyBpbnRlbmRlZCBmb3IgaXQgb3Igbm90
LiAgKi8pOw0KKyAgVm1pbmlidWZmZXJfX2RlcHRoX2Zvcl9jb21wbGV0aW9u
X3RhYmxlID0gUW5pbDsNCisNCiAgIERFRlZBUl9MSVNQICgibWluaWJ1ZmZl
ci1jb21wbGV0aW9uLXRhYmxlIiwgVm1pbmlidWZmZXJfY29tcGxldGlvbl90
YWJsZSwNCiAJICAgICAgIGRvYzogLyogQWxpc3Qgb3Igb2JhcnJheSB1c2Vk
IGZvciBjb21wbGV0aW9uIGluIHRoZSBtaW5pYnVmZmVyLg0KIFRoaXMgYmVj
b21lcyB0aGUgQUxJU1QgYXJndW1lbnQgdG8gYHRyeS1jb21wbGV0aW9uJyBh
bmQgYGFsbC1jb21wbGV0aW9ucycuDQotLSANCjIuMzAuMg0KDQo=

--ocGwpE4YpI--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45474; Package emacs. Full text available.

Message received at 45474 <at> debbugs.gnu.org:


Received: (at 45474) by debbugs.gnu.org; 18 Apr 2021 20:53:53 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Apr 18 16:53:53 2021
Received: from localhost ([127.0.0.1]:47965 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lYEQT-0003Th-Jl
	for submit <at> debbugs.gnu.org; Sun, 18 Apr 2021 16:53:53 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:61953)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1lYEQR-0003TU-Hu
 for 45474 <at> debbugs.gnu.org; Sun, 18 Apr 2021 16:53:51 -0400
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
 by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id C45AD4410AC;
 Sun, 18 Apr 2021 16:53:45 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 788AB4410A9;
 Sun, 18 Apr 2021 16:53:44 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1618779224;
 bh=QRJ0Mfy7omiDhoBMaS3iCTFqAmRco7oYP0yOnf8bS+k=;
 h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
 b=l5kxVBaw5WTxl+wsJk8Zfg+IPvwin+p2YpisgZxm4u/OED39XsjJ4OaX6gs5LX++J
 PgPea4vO2ak1cDQSjbd/24nupW93r3MgR5hITDYKhWRKq072wTKAoBMpss91GwH3v+
 dD2YRtiqwO1yNyNTvllWl+rs0wxWPd8MbabNVIYtPcW8JAECZGAk16OafB+U2/mXYc
 0FcyXnLLSAOE0nmY0oWOiIkYKv5bquNopSKjL9jbZyKHat0ZnMgdRFHe6BjxYU5Iz3
 inIGvCu1suKIQCrNaOvEac9mPifHwNjtqk2IrGVlXggkD9uUh+MBJhi8WS6HRyN6gc
 uX/Kt9lcRtbNQ==
Received: from alfajor (104-222-126-84.cpe.teksavvy.com [104.222.126.84])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 36EAF120188;
 Sun, 18 Apr 2021 16:53:44 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Drew Adams <drew.adams@HIDDEN>
Subject: Re: [External] : bug#45474: Icomplete exhibiting in recursive
 minibuffer when it =?utf-8?Q?shouldn=E2=80=99t?=
Message-ID: <jwvo8ebz56c.fsf-monnier+emacs@HIDDEN>
References: <fv2zojtus7b0tz.fsf@HIDDEN> <3ed97a9c53e0a5d4fef8@HIDDEN>
 <87fszrz21d.fsf@HIDDEN>
 <3ed97a9c530093aca93d@HIDDEN>
 <7dee3f4235d331cab291@HIDDEN> <87r1jatd34.fsf@HIDDEN>
 <7dee3f423551aaf318cb@HIDDEN> <87im4kzlfm.fsf@HIDDEN>
 <1869622e16546eafd9df@HIDDEN>
 <jwvk0p04mbj.fsf-monnier+emacs@HIDDEN>
 <SA2PR10MB44745ED4108357EC76AA7A6AF34B9@HIDDEN>
 <jwv35vo4539.fsf-monnier+emacs@HIDDEN>
 <SA2PR10MB4474642A71D8488D46B4870BF34A9@HIDDEN>
 <jwvr1j82nba.fsf-monnier+emacs@HIDDEN>
 <SA2PR10MB447493ACD79B3A73FB19D76EF34A9@HIDDEN>
 <jwvh7k31lws.fsf-monnier+emacs@HIDDEN>
 <SA2PR10MB44743A94DEACF3BC1D51E499F34A9@HIDDEN>
Date: Sun, 18 Apr 2021 16:53:43 -0400
In-Reply-To: <SA2PR10MB44743A94DEACF3BC1D51E499F34A9@HIDDEN>
 (Drew Adams's message of "Sun, 18 Apr 2021 20:11:22 +0000")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.101 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 45474
Cc: Gregory Heytings <gregory@HIDDEN>, Juri Linkov <juri@HIDDEN>,
 Dario Gjorgjevski <dario.gjorgjevski@HIDDEN>,
 "45474 <at> debbugs.gnu.org" <45474 <at> debbugs.gnu.org>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> So I guess you're not proposing that that variable no
> longer be dynamically bound.  (If that guess is wrong,
> please let me know.  Your communication is a bit "sec".)

Yes, it's a bit "sec" because your objection reduces to just "you're
proposing a change and I have no idea what you're talking about but I'll
object anyway because by definition a change may break something".

You're right, but it doesn't bring anything to the discussion.


        Stefan





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45474; Package emacs. Full text available.

Message received at 45474 <at> debbugs.gnu.org:


Received: (at 45474) by debbugs.gnu.org; 18 Apr 2021 20:11:33 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Apr 18 16:11:33 2021
Received: from localhost ([127.0.0.1]:47925 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lYDlU-0002Rw-RD
	for submit <at> debbugs.gnu.org; Sun, 18 Apr 2021 16:11:33 -0400
Received: from userp2130.oracle.com ([156.151.31.86]:39486)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <drew.adams@HIDDEN>) id 1lYDlT-0002Rc-6q
 for 45474 <at> debbugs.gnu.org; Sun, 18 Apr 2021 16:11:31 -0400
Received: from pps.filterd (userp2130.oracle.com [127.0.0.1])
 by userp2130.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 13IKBPHG194957;
 Sun, 18 Apr 2021 20:11:25 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com;
 h=from : to : cc :
 subject : date : message-id : references : in-reply-to : content-type :
 content-transfer-encoding : mime-version; s=corp-2020-01-29;
 bh=SnmUN5HRRrKLiXH7atYTTLkg0a5/qMoEnsagiwOeWTM=;
 b=KUE5nj8I9t86JVLgA0cRoOYsY4ITEL4ZxQyAJLRjBBMeXxLXDfNIWU5yyDUR/HZC3csT
 68PjNmceDq2zmYK3VvdOJQ+ypepB12EKHqGeN4lWL4K4KxVmpUaixfrAIvnZBbr+5WAW
 f++ys74boNAjgozq7/GdVndYuktU/X1GNCjgGUisVf6Dwe6mwADtfw1SM4X6uSsq7RRl
 g1yj+3CdM1ByObWQMVtIJV42gWSclf2BXAuPe1MVUjBWl3rBN3KocGT0aTXwfWj51rqb
 RclEzPEI6LdknNGPoHQDsXLdVwn5JaQ/sYsldSzFmYj69/Hz5OIxncittvOjJH0BsOlf tQ== 
Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71])
 by userp2130.oracle.com with ESMTP id 37yvea9fee-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Sun, 18 Apr 2021 20:11:24 +0000
Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1])
 by aserp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 13IK4mCj079003;
 Sun, 18 Apr 2021 20:11:24 GMT
Received: from nam11-bn8-obe.outbound.protection.outlook.com
 (mail-bn8nam11lp2170.outbound.protection.outlook.com [104.47.58.170])
 by aserp3030.oracle.com with ESMTP id 38098mrdds-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Sun, 18 Apr 2021 20:11:23 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=HjRMBdoZETrtptUYNpYtfxwosSQcwwQ6CHl8ml5bqnl0DkLYfw5Il8bdu7qJgdIp5QUMoxHaTLqEIIsMnunF37QlJpptPpy05WOar9x4b5bT4TUkfQEGZSFQda/5tQwC0slA8lVjRoXHGXdBHiM1iM9hKpnCsBTrlKARpTazjPQMHL8QAX3sK21wjK09D+RHBH031QUB2Lhn/PAz9n22W9R3pLKNZoiVBtsnVTpm9B07GGR97y30/sJFiuXYuVAS6wHHGM66C0v5xyYGtxhVPsKzzig/wwiID5LrP2Nlec1GAA1ojhaolPx5OzYAzEGhUhLePWGEGU+/DakprvzOsA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; 
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=SnmUN5HRRrKLiXH7atYTTLkg0a5/qMoEnsagiwOeWTM=;
 b=a9kw5cn1oCNI6gOLoY7T39DIVo+cq1UW9+mJTtqaoltDa84S9gMUYNiZQQiyVUONZFvGflXKk5KT6NMKwknja09oMJZRUFZfImCyvXwzEXsTEDVC2Lv2Nq0xh9kUfWF7sb93znfi6FITwN8p/MRYZpo9V+J3GcwrzUIJGsSypWI1wq8XrMkPnIH+Oeoc8J7lK2FU8L4OuKvtXJjOs5yhj5EcaBhWnETbYcAM0nDj7y3aHxK7tZNSpFPXKommO7Ppi9OdGX0L8Le8nYBDLQfloMRZsrdewTaqchnRCAG4H9Iv3LOoXjTfzkvQwL/qa6cslZoKwIWkFbqqCNZaQZxfUg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com;
 dkim=pass header.d=oracle.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=SnmUN5HRRrKLiXH7atYTTLkg0a5/qMoEnsagiwOeWTM=;
 b=Nam0AGDDVVBIGM+zptffG6FNsrYiu76SzQdhoei9kcTggfMXob3DUt1nnDSY7uCJXy7l5PeycG/hq+c1GwDCsxk4gL8Uc/5isbRs44BveCYBQ3ekYqyiq4l8KsNMZjvs2qF35OMwilUrc6c4Pqc2HJHYn1iki/BPakENBnNsxX0=
Received: from SA2PR10MB4474.namprd10.prod.outlook.com (2603:10b6:806:11b::15)
 by SA2PR10MB4812.namprd10.prod.outlook.com (2603:10b6:806:115::8)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4042.19; Sun, 18 Apr
 2021 20:11:22 +0000
Received: from SA2PR10MB4474.namprd10.prod.outlook.com
 ([fe80::2109:9725:fd4a:6494]) by SA2PR10MB4474.namprd10.prod.outlook.com
 ([fe80::2109:9725:fd4a:6494%6]) with mapi id 15.20.4042.024; Sun, 18 Apr 2021
 20:11:22 +0000
From: Drew Adams <drew.adams@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
Subject: =?Windows-1252?Q?RE:_[External]_:_bug#45474:_Icomplete_exhibiting_in_recu?=
 =?Windows-1252?Q?rsive_minibuffer_when_it_shouldn=92t?=
Thread-Topic: =?Windows-1252?Q?[External]_:_bug#45474:_Icomplete_exhibiting_in_recursiv?=
 =?Windows-1252?Q?e_minibuffer_when_it_shouldn=92t?=
Thread-Index: AQHXNIGeXHO5XwoTjUaMlqhKztssbqq6s3XQ
Date: Sun, 18 Apr 2021 20:11:22 +0000
Message-ID: <SA2PR10MB44743A94DEACF3BC1D51E499F34A9@HIDDEN>
References: <fv2zojtus7b0tz.fsf@HIDDEN> <3ed97a9c53e0a5d4fef8@HIDDEN>
 <87fszrz21d.fsf@HIDDEN>
 <3ed97a9c530093aca93d@HIDDEN>
 <7dee3f4235d331cab291@HIDDEN> <87r1jatd34.fsf@HIDDEN>
 <7dee3f423551aaf318cb@HIDDEN> <87im4kzlfm.fsf@HIDDEN>
 <1869622e16546eafd9df@HIDDEN>	<jwvk0p04mbj.fsf-monnier+emacs@HIDDEN>
 <SA2PR10MB44745ED4108357EC76AA7A6AF34B9@HIDDEN>
 <jwv35vo4539.fsf-monnier+emacs@HIDDEN>
 <SA2PR10MB4474642A71D8488D46B4870BF34A9@HIDDEN>
 <jwvr1j82nba.fsf-monnier+emacs@HIDDEN>
 <SA2PR10MB447493ACD79B3A73FB19D76EF34A9@HIDDEN>
 <jwvh7k31lws.fsf-monnier+emacs@HIDDEN>
In-Reply-To: <jwvh7k31lws.fsf-monnier+emacs@HIDDEN>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: iro.umontreal.ca; dkim=none (message not signed)
 header.d=none;iro.umontreal.ca; dmarc=none action=none
 header.from=oracle.com;
x-originating-ip: [73.170.83.28]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 035c0ac1-0f8e-47f3-10b6-08d902a62305
x-ms-traffictypediagnostic: SA2PR10MB4812:
x-microsoft-antispam-prvs: <SA2PR10MB4812CD05EA3CE9305F9DD707F34A9@HIDDEN>
x-ms-oob-tlc-oobclassifiers: OLM:2201;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: tjT2dxGB76Nxs+qLuKBx/FFdK5igrhjlPU6Y1F5HCBc4EbMyiSneMTCmSVPBB2qgNy5WCYrKJp98I95a9fPJAd3w8wqAuJVloRY+PpkcQLH8O18p+Pm/Z0+2nnilo8+F9Q7qny5Hw7vgIv28BbaKp+LW9jf5QtOin/wRd3Faqy3CFReaQX5CvQrsUhHZAfdLE7OpS4ucbykh+n+MQuuJoa4Pcgco7jzDjn7o83lxPzWJ0wIK564pkPFn1k4vZ37EDIylTWWjGIY8dVnNazPygr7t82vE31LlgiGdwGY4Fe2iV92MvoPtun7t9ya823cxHFZ87ezAtlIKHht9cjq3prCRZnCUNFB7DIR77zpxo2AgP9uZjbMcJDf5nlMe/RSzwO/MdkHVk8noAg3388oBCEKt/+r0FUhpL7/YffusSGnxJSITzHQVxLBsmPJ4skt/MGQlSdZp4BqKzjftJwPFCMwWac0JAkKAmh2BczRzMTLXwZOPiHzCOGbHCStEKqfC+AJH4ILw3C/Vd0Bb6BRev61RSB81SfcqXL0f5J+WI1CickxQYuzNqHbxtjWqOvwWJRJqFe8hbfTGXeQEp3/nZzYWCsTYwwALmEuu82685Xo=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;
 IPV:NLI; SFV:NSPM; H:SA2PR10MB4474.namprd10.prod.outlook.com; PTR:; CAT:NONE;
 SFS:(39860400002)(376002)(396003)(346002)(136003)(366004)(66476007)(66556008)(66446008)(66946007)(478600001)(83380400001)(316002)(71200400001)(54906003)(2906002)(296002)(8936002)(64756008)(26005)(186003)(38100700002)(44832011)(7696005)(86362001)(4326008)(33656002)(52536014)(6916009)(76116006)(4744005)(5660300002)(9686003)(122000001)(6506007)(55016002);
 DIR:OUT; SFP:1101; 
x-ms-exchange-antispam-messagedata: =?Windows-1252?Q?5RdVBL2l2TribDSMmwRzgZmUuFoLJm6vVbFc3xygAFOcsDZNer2SltZZ?=
 =?Windows-1252?Q?ZOq0a3J2U36F6awHQtSOw6BnHZvB+Q0Vvj5p/Ya1SwEuj0LQ7FoZpJFG?=
 =?Windows-1252?Q?lOQWwmZw5RveeMtP1uGgNLsvmWeZDiPf+Sx0hAkWoOtyolxDWxH0GX03?=
 =?Windows-1252?Q?Ao7xbDoqcBwqTH+UnxQdv2AbTKRQ6Euym6mOHbWiEF6Yw3rJfjXy2Aiy?=
 =?Windows-1252?Q?0Sh8f1T7DzjOskp07Bk4goJzHkKrAMkj9BDRtED3GKKu1CRHJlkc15kK?=
 =?Windows-1252?Q?TwIYEh+pQ0NmgmdDHtC5b7FyxY1J2fNVpYckslmJnsP23/810KuQwefw?=
 =?Windows-1252?Q?q14UytUJi4dMBsK93jmn3OGCMHKSE98+2mHnJf7rvqXynZQ+cMzBniNC?=
 =?Windows-1252?Q?2Q9PWe+MkaSMdQ6mcR/TZmZDsRNo5Rb6Re6J9nF5bq6gy3Ox/N6EFURm?=
 =?Windows-1252?Q?cout0pR4G2Jp9YLFEqI/SL/kRnS4pabN1v98CHUwh1uO7EqnzbUuDAmj?=
 =?Windows-1252?Q?LeW96UyLKe4kCUKM1ftq5r/9d4/3M0f2y7jmVWR9Jn6J5cpGP5qUGSWg?=
 =?Windows-1252?Q?PhJulHjCJnGuyuDAFs4EIE83S0PgB37b3B+pdLm2NqET5kz4kdv4KWKJ?=
 =?Windows-1252?Q?v1Y5fotgZVbavu9mf5oySDyTo7N+YK07RocQmrnihkY3+2Zz70Lw+9zh?=
 =?Windows-1252?Q?qE2ow0/IgZsVtQczOYr7f7zNNvLcNde5IQNEy5P/xNxOD/JNjNDV6qbC?=
 =?Windows-1252?Q?kLPAF9Sp7A5KXLYOhzcsoAKzUVvlNuk3Hgg/jemuYjwtrpmecUMyrSCp?=
 =?Windows-1252?Q?Dv0J5Y6SUu2roqQT806UuHl6afVph0CVeBEmi/OuVzjGDjOI2mou2F+T?=
 =?Windows-1252?Q?IzT25TYN0K7ZHtdzPvtVfZEIRAWrCmVFMIkbbGmgpDFxc6vAr+iijlyX?=
 =?Windows-1252?Q?ALE4lw4pqKlFQ+C3S//plGrVKnmWg1KJsTxy0gg9EoJDLJ/nNJh/Z0iD?=
 =?Windows-1252?Q?WPhcCiJZxu48okLnGxZO7R2vgATESZAMRNUpcARNrT0AZo3f+bV6yKk5?=
 =?Windows-1252?Q?LcnoV6atUabdBSxyf4+lcUm7opsARadTwFyfB2IW0Z6gatLP3BeZUfxq?=
 =?Windows-1252?Q?i/22O6Ki3W7hC6VRFLSydnINWix+GvYCaaddsEjCwiEovP5bxTBWnnGE?=
 =?Windows-1252?Q?x61Jt2nnyUkehJDPTgiY/orD4R/+8uE5LNVZuynFdC9b8y00/Z0juHGq?=
 =?Windows-1252?Q?SyB9TuihC+P1ifGGG3LO2pnEfu6dTym9X1ckz3zeedS7Vv2ea+Llfj+U?=
 =?Windows-1252?Q?CZ6n2LkBtQVI72iQHliOseGt/3z2BnFWACVr4cFw2ZNa3/oaIPaJ/lU6?=
 =?Windows-1252?Q?vRWwoDLKkR5k4jnYvx+q3YQSoMGjOC1l7n4YKsfW0R8YLL5HBm5v8AdX?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SA2PR10MB4474.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 035c0ac1-0f8e-47f3-10b6-08d902a62305
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Apr 2021 20:11:22.4449 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: RTtM+cNHm/J2avkvt4hWLAW0CM9dRcDUTut/o9BpM3ftc9+HWygJuVC7dawqznacNFCwvRoJxPEzDgbLdqk/CA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA2PR10MB4812
X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9958
 signatures=668683
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0
 spamscore=0 phishscore=0
 mlxlogscore=895 malwarescore=0 bulkscore=0 mlxscore=0 adultscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104060000
 definitions=main-2104180143
X-Proofpoint-GUID: 7fwL9un46Fhu44izPR_PghIzubPDQ31T
X-Proofpoint-ORIG-GUID: 7fwL9un46Fhu44izPR_PghIzubPDQ31T
X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9958
 signatures=668683
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 impostorscore=0
 phishscore=0 mlxscore=0
 suspectscore=0 lowpriorityscore=0 mlxlogscore=999 spamscore=0 bulkscore=0
 adultscore=0 malwarescore=0 clxscore=1015 priorityscore=1501
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104060000
 definitions=main-2104180143
X-Spam-Score: -1.4 (-)
X-Debbugs-Envelope-To: 45474
Cc: Gregory Heytings <gregory@HIDDEN>, Juri Linkov <juri@HIDDEN>,
 Dario Gjorgjevski <dario.gjorgjevski@HIDDEN>,
 "45474 <at> debbugs.gnu.org" <45474 <at> debbugs.gnu.org>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.4 (--)

> > Am I mistaken that you seem to have switched from a
> > consideration of dynamic vs lexical to global dynamic
> > vs buffer-local dynamic?
>=20
> Yes you are.

So I guess you're not proposing that that variable no
longer be dynamically bound.  (If that guess is wrong,
please let me know.  Your communication is a bit "sec".)

This is what made me think that was your proposal, at
the outset:

  SM: "instead of being "set" by dynamic scoping"

You did mention buffer-local, but you also mentioned
"instead of" dynamic scoping.  It's still not too clear
to me what you have in mind.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45474; Package emacs. Full text available.

Message received at 45474 <at> debbugs.gnu.org:


Received: (at 45474) by debbugs.gnu.org; 18 Apr 2021 18:35:35 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Apr 18 14:35:35 2021
Received: from localhost ([127.0.0.1]:47759 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lYCGd-0006Lh-Av
	for submit <at> debbugs.gnu.org; Sun, 18 Apr 2021 14:35:35 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:1612)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1lYCGb-0006LU-7c
 for 45474 <at> debbugs.gnu.org; Sun, 18 Apr 2021 14:35:34 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 009CF80801;
 Sun, 18 Apr 2021 14:35:28 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id B752580618;
 Sun, 18 Apr 2021 14:35:26 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1618770926;
 bh=bjVWMp3Y+WokHqGdE2K5dIlXYP2TcpAaSlv/LtGNaqM=;
 h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
 b=le6X+EXGGhezcwbuuubqzYn70AOxmEblMNlBp7wgK7otojhUTaalnpw32+Y723TI7
 59p85oJ8dUrcffNQxvN1znNHwx4DJrMn5bVoZh1A4W8s0bOBlJr6MY838kxliosuVS
 Tlu1wmCQuKNAZDYDFJNBeVeW+nKS23qJ+bW4kkTpgSh8c7vyjkySTYSgX1YgLujC/U
 0xkLl6Jtaa53Fj48GF5AA575SYJwS+dp10Pc9+VDOg5+w3ImoxaWHQXaE5OJ9/YkCz
 b1kYcvu4xEfBVmz34nLFiaur6NhREHFubO/AuI4vQ6xT3RSb+TK7eJdO6KdzqYE/Pl
 8a1zViIktaitA==
Received: from alfajor (104-222-126-84.cpe.teksavvy.com [104.222.126.84])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 6D4A2120312;
 Sun, 18 Apr 2021 14:35:26 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Drew Adams <drew.adams@HIDDEN>
Subject: Re: [External] : bug#45474: Icomplete exhibiting in recursive
 minibuffer when it =?utf-8?Q?shouldn=E2=80=99t?=
Message-ID: <jwvh7k31lws.fsf-monnier+emacs@HIDDEN>
References: <fv2zojtus7b0tz.fsf@HIDDEN> <3ed97a9c53e0a5d4fef8@HIDDEN>
 <87fszrz21d.fsf@HIDDEN>
 <3ed97a9c530093aca93d@HIDDEN>
 <7dee3f4235d331cab291@HIDDEN> <87r1jatd34.fsf@HIDDEN>
 <7dee3f423551aaf318cb@HIDDEN> <87im4kzlfm.fsf@HIDDEN>
 <1869622e16546eafd9df@HIDDEN>
 <jwvk0p04mbj.fsf-monnier+emacs@HIDDEN>
 <SA2PR10MB44745ED4108357EC76AA7A6AF34B9@HIDDEN>
 <jwv35vo4539.fsf-monnier+emacs@HIDDEN>
 <SA2PR10MB4474642A71D8488D46B4870BF34A9@HIDDEN>
 <jwvr1j82nba.fsf-monnier+emacs@HIDDEN>
 <SA2PR10MB447493ACD79B3A73FB19D76EF34A9@HIDDEN>
Date: Sun, 18 Apr 2021 14:35:25 -0400
In-Reply-To: <SA2PR10MB447493ACD79B3A73FB19D76EF34A9@HIDDEN>
 (Drew Adams's message of "Sun, 18 Apr 2021 15:42:34 +0000")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.053 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 45474
Cc: Gregory Heytings <gregory@HIDDEN>, Juri Linkov <juri@HIDDEN>,
 Dario Gjorgjevski <dario.gjorgjevski@HIDDEN>,
 "45474 <at> debbugs.gnu.org" <45474 <at> debbugs.gnu.org>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Am I mistaken that you seem to have switched from a
> consideration of dynamic vs lexical to global dynamic
> vs buffer-local dynamic?

Yes you are.


        Stefan





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45474; Package emacs. Full text available.

Message received at 45474 <at> debbugs.gnu.org:


Received: (at 45474) by debbugs.gnu.org; 18 Apr 2021 15:42:40 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Apr 18 11:42:40 2021
Received: from localhost ([127.0.0.1]:47503 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lY9ZI-0003yA-BJ
	for submit <at> debbugs.gnu.org; Sun, 18 Apr 2021 11:42:40 -0400
Received: from mx0a-00069f02.pphosted.com ([205.220.165.32]:45184)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <drew.adams@HIDDEN>) id 1lY9ZG-0003y2-Cw
 for 45474 <at> debbugs.gnu.org; Sun, 18 Apr 2021 11:42:39 -0400
Received: from pps.filterd (m0246617.ppops.net [127.0.0.1])
 by mx0b-00069f02.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id
 13IFfcM7007752; Sun, 18 Apr 2021 15:42:37 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com;
 h=from : to : cc :
 subject : date : message-id : references : in-reply-to : content-type :
 content-transfer-encoding : mime-version; s=corp-2020-01-29;
 bh=Aud5HzI5XvpmueBamfs9uJkgnnpH/3Jibd7auYJBgZo=;
 b=XS2/h/8nNlzBS2m5CrkVGUQjeD6vr0dOIYS55aPP+ZEPbbmsM2LM54YmNWlErYxR1TeY
 QdvGz0DBVE9Os8mPs72NFM6IyVL1/al8CyWgK+e5X8svFORoMiXwPpNtM3ChVSI9LZx/
 LYRwzp8qI1unBqkBztT2wRGV0Tj8tEPsxuY5ImrnEwK2To2neh6/KD5sLUYMvVdmTRE5
 eSG4oKltcX7iAyJPkQVnSJopJLpOhGAkgmFD3p3oBvgP2BZDSRnTMm3MKyXj2k5cZA44
 JQD8WMNkUFnKhxnLc2kK7MevkVkq3kzdkTOLQwrPddsCbU0PMODJYKIvXmv6rOtzFIp9 7g== 
Received: from oracle.com (aserp3020.oracle.com [141.146.126.70])
 by mx0b-00069f02.pphosted.com with ESMTP id 37yr7s8d6t-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Sun, 18 Apr 2021 15:42:37 +0000
Received: from aserp3020.oracle.com (aserp3020.oracle.com [127.0.0.1])
 by pps.podrdrct (8.16.0.36/8.16.0.36) with SMTP id 13IFgarh193862;
 Sun, 18 Apr 2021 15:42:36 GMT
Received: from nam11-bn8-obe.outbound.protection.outlook.com
 (mail-bn8nam11lp2176.outbound.protection.outlook.com [104.47.58.176])
 by aserp3020.oracle.com with ESMTP id 3809jwt36u-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Sun, 18 Apr 2021 15:42:36 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=ghm8aRsYCitnkgd5tGGmr9BFlO3lA9ajB/9cbRMco+giSxgnt7nMOHiejU33GzgYm1KoJoEuSS+Nt15GTJkztjWKnk2SKonVX/SpS+oJbgNOJiaP2EdZRSlT5N8IPwMXkPA9iN/JJHv//VMfRboCsxWOuHI6wgi76UV1TMJxvWHXtfJTj6IefuF2nFnpIqrs5jbEANI5lAdkDOFQDW/n8xrfy3kj7BPGvGsBz0gmw3opz2de7dFc64hHcjl1nUJZwzrR4fb5KLKeKEI8XNQto/CqLHeLEqXbpfwDjmFO8DnS9tl+KF8d9gmZM/44hzgRDpUXB2D2GsTVmdGhUHN8DA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; 
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=Aud5HzI5XvpmueBamfs9uJkgnnpH/3Jibd7auYJBgZo=;
 b=Zk7J96VDuByOO1rYU5Q3ympvNef+qomTDHJbRmoHHkNBkMkVkNFrqj9BVldlii3p52Anqqo1VKC6wF/Zg6UN3ALDjasg+H/+T2KX3V/dSAyQFjYcKv2w944+D9aIKWRZ4jPJ6ML3iw6KptOSIt8jhhAbc2M6aZxcB+4bOc+bognG/XMnfZ8YYf+21D60e+6iSESEPzrQkja3G5Qf3vDVjIPPUiKJh0JVhqMdaZe/Ex8v/F3IZPzcx2kr1gvYB9AAgtY6fzVpTeod0qZR2TBVJ4F/ITIHvu/LpKumF75SEnqfwC8TK5GLBH3kJfg+nHtSA5ltwPY7WZmcGwgvYCuOVQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com;
 dkim=pass header.d=oracle.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=Aud5HzI5XvpmueBamfs9uJkgnnpH/3Jibd7auYJBgZo=;
 b=TBOoHXp00FI/DAGmQtDSt5Iq4kgW2ImRY7mGJeJU91O+VpTFdtTR0dQ9xP7VMjCB8kNm2kR8zRHJzAoXw406dVYj9VBegYi6BIWZBgu++otFgq0BElGaPfmFpSnIl2FVOxerCSFwHJBJTEeYFZS5tbeWDJIK/yPGjcwkw67RWr8=
Received: from SA2PR10MB4474.namprd10.prod.outlook.com (2603:10b6:806:11b::15)
 by SA2PR10MB4523.namprd10.prod.outlook.com (2603:10b6:806:113::13)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4042.20; Sun, 18 Apr
 2021 15:42:34 +0000
Received: from SA2PR10MB4474.namprd10.prod.outlook.com
 ([fe80::2109:9725:fd4a:6494]) by SA2PR10MB4474.namprd10.prod.outlook.com
 ([fe80::2109:9725:fd4a:6494%6]) with mapi id 15.20.4042.024; Sun, 18 Apr 2021
 15:42:34 +0000
From: Drew Adams <drew.adams@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
Subject: =?Windows-1252?Q?RE:_[External]_:_bug#45474:_Icomplete_exhibiting_in_recu?=
 =?Windows-1252?Q?rsive_minibuffer_when_it_shouldn=92t?=
Thread-Topic: =?Windows-1252?Q?[External]_:_bug#45474:_Icomplete_exhibiting_in_recursiv?=
 =?Windows-1252?Q?e_minibuffer_when_it_shouldn=92t?=
Thread-Index: AQHXNBDo1tMcJ80WgEmUaa3dA2AlIqq6Xuig
Date: Sun, 18 Apr 2021 15:42:34 +0000
Message-ID: <SA2PR10MB447493ACD79B3A73FB19D76EF34A9@HIDDEN>
References: <fv2zojtus7b0tz.fsf@HIDDEN> <3ed97a9c53e0a5d4fef8@HIDDEN>
 <87fszrz21d.fsf@HIDDEN>
 <3ed97a9c530093aca93d@HIDDEN>
 <7dee3f4235d331cab291@HIDDEN> <87r1jatd34.fsf@HIDDEN>
 <7dee3f423551aaf318cb@HIDDEN> <87im4kzlfm.fsf@HIDDEN>
 <1869622e16546eafd9df@HIDDEN>	<jwvk0p04mbj.fsf-monnier+emacs@HIDDEN>
 <SA2PR10MB44745ED4108357EC76AA7A6AF34B9@HIDDEN>
 <jwv35vo4539.fsf-monnier+emacs@HIDDEN>
 <SA2PR10MB4474642A71D8488D46B4870BF34A9@HIDDEN>
 <jwvr1j82nba.fsf-monnier+emacs@HIDDEN>
In-Reply-To: <jwvr1j82nba.fsf-monnier+emacs@HIDDEN>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: iro.umontreal.ca; dkim=none (message not signed)
 header.d=none;iro.umontreal.ca; dmarc=none action=none
 header.from=oracle.com;
x-originating-ip: [73.170.83.28]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 2f039107-2b9c-4783-21da-08d9028095f9
x-ms-traffictypediagnostic: SA2PR10MB4523:
x-microsoft-antispam-prvs: <SA2PR10MB4523C00C60190BA72A8A9563F34A9@HIDDEN>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: Kl+hUgUC6HJVPD28e+RvUGj3GsalyW6s4P3V5rcXd+pUwGC2vqNiq3gFcOA0pks+Ocp/yx9BpuBPqb/ISkXncZOUuy34gXzP/vOxcu4n6HQhxb8wV/uuhfg9VeJ6kA2mAqya7fZsldL8dEJPQ5354vA1Msd7J2NGlCjGz0oc7li5D4ohWUHm29yJ9+IJlQYoVkGHwD7lqTjBTbhX6IMDn6H14RbHxKJEFsJbzzrXUMAXJkKXY5dv/j/X6tWnhpXO18Je5B8k8V6+efQD2zNfTD/WGnmnq27tuTrz1sCbUmKO3gDudZugHsoyZVpfi/+om9m9V7fyjlpA9Rf7fQbarIDS2O2cCF80jcceJhhvCicjI9rxuSjHGQSt+WTcaL+zsje/3qACVN1eZLncQi2eKNIpgqwVlY6y/o6Or17W68S/rg5IPY8XX2Z8HWFut3dhAW/m9G7ciRjVR5oO53sB9stgZU9FaNUbbAjRBcLptcY0uXPVu7F+4xbf4aQlybSA7AgBLm8Vk4NU300+cpzvyzAASQZnFF6r1009WRXOnY5hgzeDRN8Y05B55RmbC53Rp2YboWh3A86LYvzLPToqyxR+h18q4RlAegmwnRtXg7c=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;
 IPV:NLI; SFV:NSPM; H:SA2PR10MB4474.namprd10.prod.outlook.com; PTR:; CAT:NONE;
 SFS:(346002)(396003)(376002)(39860400002)(366004)(136003)(86362001)(26005)(33656002)(71200400001)(6916009)(55016002)(296002)(478600001)(316002)(6506007)(7696005)(52536014)(54906003)(66556008)(66946007)(64756008)(4326008)(8936002)(66446008)(2906002)(66476007)(38100700002)(186003)(9686003)(122000001)(5660300002)(76116006)(44832011);
 DIR:OUT; SFP:1101; 
x-ms-exchange-antispam-messagedata: =?Windows-1252?Q?cizohEqGDHTNYJVnaIsiR3xxN6mA5RiPxxIMRVdsM0CIOJQZ/eT+G/Rb?=
 =?Windows-1252?Q?8VQRFEzU4eAWWTz5qJglG8DjSi9ESDuVj9vPsACiKIsp1quVlffKgJQ8?=
 =?Windows-1252?Q?YTzcNZzPWd9AGEPz4IBzPiaHHBalemraZsdrNNh7X3SGCAo6x3+Jay8S?=
 =?Windows-1252?Q?ZCEyOiEF2L3W2EWp5cRzrA7CeKUiUK8ynyKR+6TOy2OQZGkofJaVKvO1?=
 =?Windows-1252?Q?E1iHEqFCUBsdbRliJlqI7Tqeb1gigTRRArGG4Y8NAxYYSTN2RIIvFcTr?=
 =?Windows-1252?Q?t79XEkdDS78+lIIpBdtJTqOWzXI4sGxFZwugL0TTulWXCkyWZe5xL6WZ?=
 =?Windows-1252?Q?RhB1LEju1tiwJEGwT3gd02xdCvr61K3+Jf9aKW2nlxDIZNwD5RA9HS7H?=
 =?Windows-1252?Q?Bs4kyeMZZAyldRxgIgz+hYq3wL4Mx16ydlJnPbe0Mw4PQ5qfbYA6CS0Z?=
 =?Windows-1252?Q?H9gAK279DBFTYAT/B8LYhNs0E+ymUwPqdxgbcoMHS6C1D/zFXLji6u1j?=
 =?Windows-1252?Q?+bdQk9Tb0vPLfA8DMDNsdSS9GYadpJFuiBpNhNceiKtJV0VZ216tb9Pn?=
 =?Windows-1252?Q?QY62Grc1+SO7vcqFO480xsExLxJns7tUm9+3NOX9xNpMQlul8I4JSQTh?=
 =?Windows-1252?Q?kwshVLYz8gax/CqrCH4aH8lTIZWca1vcw1Ozdn6rfTeFxwgboyX0dbWy?=
 =?Windows-1252?Q?LbeWoo1FVSFAlCzDXt+DkxcbjrG08CK6teEWZNW8cuVNnYwUqCn+g/ch?=
 =?Windows-1252?Q?kWecU8hPBvZoaz6EuFSPQQDBbRVkQ3mNhzz2tYf1LStGyG/wHoq7rNnw?=
 =?Windows-1252?Q?UnWl6iABV3hCXFmslQjWfo7w7E7mjxntFXzfPIkqp7CQVJNi+myPYJok?=
 =?Windows-1252?Q?I0ib9oP0yrgPmDezB2XPenyv82VE/WYjaFEMMTvHPvxGSw57eJ5KlDbe?=
 =?Windows-1252?Q?4LaHYolDgmzu8WiKgSRgoiLZfg8pjuhBHY3EwJ0KyTfCqDjScI5iy92y?=
 =?Windows-1252?Q?DVCFqq+wfdnVQ8ODb5T0j/DdeCu48LTz9OUQ78TGc7cfgCEVprXBAD1g?=
 =?Windows-1252?Q?fTXlE3ujRsmsZmETGKjRnywOVHNxt3B5o4w9Y+l0dXuXw4x7jGDX7Mik?=
 =?Windows-1252?Q?1QDvVTEhuxKo76QLnAkkbrYUhPHQbXvVGk3JqjBPdhB6NzmclzQwq7GR?=
 =?Windows-1252?Q?br2j4oa1epQ5LJ6fY5RqFp9d+Dh4AZXaFk5ZacLCF4k6avgjwLCv73fh?=
 =?Windows-1252?Q?stNkStkyNzmOCZHUD/oUBFg4X/2mad92JpSPLiA54uSHw7CDqyfi+Ppx?=
 =?Windows-1252?Q?t9Rgr95KjqcB5YNGBtasUawZ3IKyoPrH6pmcrdSOuFgrl3Swo443Knrb?=
 =?Windows-1252?Q?LUN7TXH4wMNnRLoPZ1ykkPAC+DdphKbTwkJuX9uZFfmpHmXkT0VTUKvK?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SA2PR10MB4474.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 2f039107-2b9c-4783-21da-08d9028095f9
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Apr 2021 15:42:34.3901 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: gRR94HFbBVOK7bGYLR49MMiPZACJUDHTIOzW+APddq6gLY1Fi59n9w7jYaesD0na8jZ9z9D094tqg7aIDZwMnw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA2PR10MB4523
X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9958
 signatures=668683
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0
 bulkscore=0 malwarescore=0
 suspectscore=0 phishscore=0 spamscore=0 mlxlogscore=814 mlxscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104060000
 definitions=main-2104180111
X-Proofpoint-GUID: 8McDI3g7iGvfVg9XWIRgU193rn7dMF21
X-Proofpoint-ORIG-GUID: 8McDI3g7iGvfVg9XWIRgU193rn7dMF21
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 45474
Cc: Gregory Heytings <gregory@HIDDEN>, Juri Linkov <juri@HIDDEN>,
 Dario Gjorgjevski <dario.gjorgjevski@HIDDEN>,
 "45474 <at> debbugs.gnu.org" <45474 <at> debbugs.gnu.org>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

> > I don't know what more to say.  Not being able to
> > have `minibuffer-completion-table' dynamically
> > scoped and settable/redefinable as such a variable
> > would effectively destroy Icicles features that
> > rely on exactly that ability.
>=20
> Let me rephrase my question:
> What makes you think that having them be set
> buffer-locally rather than via a global let-binding
> would prevent Icicles setting/redefining them?

Let-binding of global, dynamic variables (defvar)?
Or something else?

I don't know what making such vars buffer-local might
do to the (Icicles) behavior.  It's not even clear to
me what buffer-local means for the minibuffer these
days (what with experiments/proposals about changing
its mode etc.).

It's possible that the effect wouldn't be nefarious.
But it's also possible it would be.  During minibuffer
use, other buffers can be current at various points,
for example.  But I'm not sure there's a problem there.

My reason for posting was that you were, or I thought
you were, contrasting dynamic and lexical binding, of
`minibuffer-completion-table' (and maybe similar vars).

It's dynamic binding that my code depends on for such
vars.  Dunno how important (for my code) global vs
buffer-local is in this context.  That's something
different.

Am I mistaken that you seem to have switched from a
consideration of dynamic vs lexical to global dynamic
vs buffer-local dynamic?

I'm sorry; I haven't followed this discussion.  I
just wanted to give a heads-up that it would be
problematic for me if such vars were made lexical or,
say, were simply passed as args.  I bind and set them
as dynamically-scoped vars.

If necessary, I can dig out examples of what I do.
I hope it doesn't come to that, though.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45474; Package emacs. Full text available.

Message received at 45474 <at> debbugs.gnu.org:


Received: (at 45474) by debbugs.gnu.org; 18 Apr 2021 14:45:09 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Apr 18 10:45:09 2021
Received: from localhost ([127.0.0.1]:47396 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lY8fb-0002Wp-SK
	for submit <at> debbugs.gnu.org; Sun, 18 Apr 2021 10:45:08 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:12011)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1lY8fa-0002W2-2m
 for 45474 <at> debbugs.gnu.org; Sun, 18 Apr 2021 10:45:06 -0400
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)
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==
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)
From: Stefan Monnier <monnier@HIDDEN>
To: Gregory Heytings <gregory@HIDDEN>
Subject: Re: bug#45474: Icomplete exhibiting in recursive minibuffer when it
 =?utf-8?Q?shouldn=E2=80=99t?=
Message-ID: <jwvfszn3by1.fsf-monnier+emacs@HIDDEN>
References: <fv2zojtus7b0tz.fsf@HIDDEN> <3ed97a9c53e0a5d4fef8@HIDDEN>
 <87fszrz21d.fsf@HIDDEN>
 <3ed97a9c530093aca93d@HIDDEN>
 <7dee3f4235d331cab291@HIDDEN> <87r1jatd34.fsf@HIDDEN>
 <7dee3f423551aaf318cb@HIDDEN> <87im4kzlfm.fsf@HIDDEN>
 <1869622e16546eafd9df@HIDDEN>
 <jwvk0p04mbj.fsf-monnier+emacs@HIDDEN>
 <1869622e16dc36c3f2fd@HIDDEN>
Date: Sun, 18 Apr 2021 10:44:57 -0400
In-Reply-To: <1869622e16dc36c3f2fd@HIDDEN> (Gregory Heytings's message
 of "Sat, 17 Apr 2021 22:16:16 +0000")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.101 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 45474
Cc: Dario Gjorgjevski <dario.gjorgjevski@HIDDEN>, 45474 <at> debbugs.gnu.org,
 Juri Linkov <juri@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

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





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45474; Package emacs. Full text available.

Message received at 45474 <at> debbugs.gnu.org:


Received: (at 45474) by debbugs.gnu.org; 18 Apr 2021 05:08:46 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Apr 18 01:08:46 2021
Received: from localhost ([127.0.0.1]:45109 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lXzfq-00028D-6h
	for submit <at> debbugs.gnu.org; Sun, 18 Apr 2021 01:08:46 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:49661)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1lXzfp-00027y-DF
 for 45474 <at> debbugs.gnu.org; Sun, 18 Apr 2021 01:08:45 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 3914B10022E;
 Sun, 18 Apr 2021 01:08:40 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 752DC1000F4;
 Sun, 18 Apr 2021 01:08:38 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1618722518;
 bh=W5LBnNue5TMACip+LnZmagN1KVipHMk92gXBRN55cBw=;
 h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
 b=Dk3n4yQ5FxA8EC+8URONTRWpzvFKnSey2BX9uuvBZTZjwZKiYTXRa47wD+cKAqWLN
 JZd13Dvtl8slvE92LJxqOTHL8EPJo5Q9zH03M2jOBjfCoDIEEf45DTDYlzag6AIZLP
 Ste7kgdFF8Woilgh8Be02G8CKP86rcZzDIOzNFykHO0Ym4s9puxoZmIyfjouzLicQV
 lhlOTTpIn0wNrd2+/op4bR4PPQqUt+Du9It7HQ8wu+zgsMWmvVLE1GNIowuL2Rx3OQ
 iA4QIohVWKxxMPcdVOgJkZwp3Ds279mD1j50b7I8Z+Kw9Cf4n+qJUgsQId+pOQksdb
 hYfxUGXgt86og==
Received: from alfajor (104-222-126-84.cpe.teksavvy.com [104.222.126.84])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id E75E8120283;
 Sun, 18 Apr 2021 01:08:37 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Drew Adams <drew.adams@HIDDEN>
Subject: Re: [External] : bug#45474: Icomplete exhibiting in recursive
 minibuffer when it =?utf-8?Q?shouldn=E2=80=99t?=
Message-ID: <jwvr1j82nba.fsf-monnier+emacs@HIDDEN>
References: <fv2zojtus7b0tz.fsf@HIDDEN> <3ed97a9c53e0a5d4fef8@HIDDEN>
 <87fszrz21d.fsf@HIDDEN>
 <3ed97a9c530093aca93d@HIDDEN>
 <7dee3f4235d331cab291@HIDDEN> <87r1jatd34.fsf@HIDDEN>
 <7dee3f423551aaf318cb@HIDDEN> <87im4kzlfm.fsf@HIDDEN>
 <1869622e16546eafd9df@HIDDEN>
 <jwvk0p04mbj.fsf-monnier+emacs@HIDDEN>
 <SA2PR10MB44745ED4108357EC76AA7A6AF34B9@HIDDEN>
 <jwv35vo4539.fsf-monnier+emacs@HIDDEN>
 <SA2PR10MB4474642A71D8488D46B4870BF34A9@HIDDEN>
Date: Sun, 18 Apr 2021 01:08:37 -0400
In-Reply-To: <SA2PR10MB4474642A71D8488D46B4870BF34A9@HIDDEN>
 (Drew Adams's message of "Sun, 18 Apr 2021 04:04:36 +0000")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.023 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 45474
Cc: Gregory Heytings <gregory@HIDDEN>, Juri Linkov <juri@HIDDEN>,
 Dario Gjorgjevski <dario.gjorgjevski@HIDDEN>,
 "45474 <at> debbugs.gnu.org" <45474 <at> debbugs.gnu.org>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> I don't know what more to say.  Not being able to
> have `minibuffer-completion-table' dynamically
> scoped and settable/redefinable as such a variable
> would effectively destroy Icicles features that
> rely on exactly that ability.

Let me rephrase my question:
What makes you think that having them be set buffer-locally rather than via
a global let-binding would prevent Icicles setting/redefining them?


        Stefan






Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45474; Package emacs. Full text available.

Message received at 45474 <at> debbugs.gnu.org:


Received: (at 45474) by debbugs.gnu.org; 18 Apr 2021 04:04:43 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Apr 18 00:04:43 2021
Received: from localhost ([127.0.0.1]:45041 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lXyfr-0000Rk-Cr
	for submit <at> debbugs.gnu.org; Sun, 18 Apr 2021 00:04:43 -0400
Received: from mx0a-00069f02.pphosted.com ([205.220.165.32]:32230)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <drew.adams@HIDDEN>) id 1lXyfo-0000Rb-Jg
 for 45474 <at> debbugs.gnu.org; Sun, 18 Apr 2021 00:04:41 -0400
Received: from pps.filterd (m0246629.ppops.net [127.0.0.1])
 by mx0b-00069f02.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id
 13I44dRf010054; Sun, 18 Apr 2021 04:04:39 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com;
 h=from : to : cc :
 subject : date : message-id : references : in-reply-to : content-type :
 content-transfer-encoding : mime-version; s=corp-2020-01-29;
 bh=NjC0/hiS9BCJ48caik8NMMJRBHN6Q/aJ6UF34ESLKgM=;
 b=s/Kio+PwUiy4vS//9C4SeObsQj2O/XtjImv0kM3Nr/skFDRBd64Agv2LpTAqpRX4INvd
 VtvBOpUaUUJlRnC87aHnB1kzQinhdfGyIUb58xfscsEBetsxRyTz1yAlC7gOsO7sCWek
 gEL64KADxXBtCXxJCzem+MBp1Oql1jdbEMrp/V5RS4KGvQ7WpZpLSmF/pJS0+TcqCuqu
 i3r5JrKl5ICPVGZZFNdqCGZ7FZlRz9NKvF8XWYEgidYGQBUO2rahXF099/6RCHwykNei
 8NQCTHaE3O8nmaUwwcjfvzISWZExeqPtuRuJcaJwxElxo0H37Koxn61MCatKoVe3r8iX Tw== 
Received: from oracle.com (aserp3020.oracle.com [141.146.126.70])
 by mx0b-00069f02.pphosted.com with ESMTP id 3806v9r2s0-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Sun, 18 Apr 2021 04:04:39 +0000
Received: from aserp3020.oracle.com (aserp3020.oracle.com [127.0.0.1])
 by pps.podrdrct (8.16.0.36/8.16.0.36) with SMTP id 13I44cOp025721;
 Sun, 18 Apr 2021 04:04:38 GMT
Received: from nam11-bn8-obe.outbound.protection.outlook.com
 (mail-bn8nam11lp2174.outbound.protection.outlook.com [104.47.58.174])
 by aserp3020.oracle.com with ESMTP id 3809jwcyum-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Sun, 18 Apr 2021 04:04:38 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=MOCSAza7z3GV18vbS75kVF2Jqk+BI5EaM86yTz/HomB5RrHbDvPweloNwiL4e1952nO3+PCXmxHLJPn0fW4Vp0aOvmgOeIsyWQcdmVYUbViGOcy1n/tSs27Gqx+UNr7HAfioMZno7IS6DBLDTpAaG+LX5wo+uGIJd+nOBY1kp+Ka3/Wuv0Q5HWdn2GVMAFKjVOFSjXVrMIL7sihq9mQG7ezRa0UiIK5fKnx+NQg8FpqRzr+Tc77wyTU5XC57II6eecOYPefCyZt+SqBXeD8mo+FDmNPyGyByOugzGbVPZ2hRUFFVbhsT+rysVqTAWFMCLBBRK0D4dzTh6WWGv5oZjw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; 
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=NjC0/hiS9BCJ48caik8NMMJRBHN6Q/aJ6UF34ESLKgM=;
 b=IWkwFGOAmrOblRVTMXHJwfG6sVsUFb7Ux9LKFqqFwd6zzI95QJPFKKELonZWWqNk4XV9JHis2M+HsyNKGQ+rQ8YBVktRV3nWc3bumViS5y43vUvyYGd6s3MsRK0IWvq8BvxAsWjgI2vEIJwN5usqJiYXnlz9mYn4bgKt2utaCGcpqPjOIDuvr0A/q38LepvWhKMivHFPx4Y2aWug7AHu/yeRqd5nOM48nBvkDOGvlqgjzwnGKuCjnq7dx+2QzMZkOzOJa/zUNgySqUTzJT6FRZoNGUirrY67zXfEd/nFflZ7VaO0pE8Hys9IueolKClYno8hVdH9mwM2jJ36wmwfFQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com;
 dkim=pass header.d=oracle.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=NjC0/hiS9BCJ48caik8NMMJRBHN6Q/aJ6UF34ESLKgM=;
 b=l/ZfpS1U7CiHUaFJAZSoFmsuFljVGhCdBonejuSK+NAuwWJZRG6nYbSHsgZ77OYhyq3Yw+VE7RXa7muc9aLYvPmRqyU7SRhe4763GF7NiWlMxZuREIFGoHneNg2q4e1o+8ExtkYBYXNlKG5DJyjQwpV4aQWV0D5CchfBOZUExJY=
Received: from SA2PR10MB4474.namprd10.prod.outlook.com (2603:10b6:806:11b::15)
 by SN6PR10MB2736.namprd10.prod.outlook.com (2603:10b6:805:44::32)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4042.19; Sun, 18 Apr
 2021 04:04:36 +0000
Received: from SA2PR10MB4474.namprd10.prod.outlook.com
 ([fe80::2109:9725:fd4a:6494]) by SA2PR10MB4474.namprd10.prod.outlook.com
 ([fe80::2109:9725:fd4a:6494%6]) with mapi id 15.20.4042.024; Sun, 18 Apr 2021
 04:04:36 +0000
From: Drew Adams <drew.adams@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
Subject: =?Windows-1252?Q?RE:_[External]_:_bug#45474:_Icomplete_exhibiting_in_recu?=
 =?Windows-1252?Q?rsive_minibuffer_when_it_shouldn=92t?=
Thread-Topic: =?Windows-1252?Q?[External]_:_bug#45474:_Icomplete_exhibiting_in_recursiv?=
 =?Windows-1252?Q?e_minibuffer_when_it_shouldn=92t?=
Thread-Index: AQHXNAc7XypQUxvUc0SIZezbfQ8iuKq5pslw
Date: Sun, 18 Apr 2021 04:04:36 +0000
Message-ID: <SA2PR10MB4474642A71D8488D46B4870BF34A9@HIDDEN>
References: <fv2zojtus7b0tz.fsf@HIDDEN> <3ed97a9c53e0a5d4fef8@HIDDEN>
 <87fszrz21d.fsf@HIDDEN>
 <3ed97a9c530093aca93d@HIDDEN>
 <7dee3f4235d331cab291@HIDDEN> <87r1jatd34.fsf@HIDDEN>
 <7dee3f423551aaf318cb@HIDDEN> <87im4kzlfm.fsf@HIDDEN>
 <1869622e16546eafd9df@HIDDEN>	<jwvk0p04mbj.fsf-monnier+emacs@HIDDEN>
 <SA2PR10MB44745ED4108357EC76AA7A6AF34B9@HIDDEN>
 <jwv35vo4539.fsf-monnier+emacs@HIDDEN>
In-Reply-To: <jwv35vo4539.fsf-monnier+emacs@HIDDEN>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: iro.umontreal.ca; dkim=none (message not signed)
 header.d=none;iro.umontreal.ca; dmarc=none action=none
 header.from=oracle.com;
x-originating-ip: [73.170.83.28]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: c4f26092-3f60-4d4d-c9dd-08d9021f14ce
x-ms-traffictypediagnostic: SN6PR10MB2736:
x-microsoft-antispam-prvs: <SN6PR10MB273672F3279E0A322AC93AEEF34A9@HIDDEN>
x-ms-oob-tlc-oobclassifiers: OLM:7219;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 8Sh917i+ixu+WVyZTQoerOPkmcTv3kxZLxizoXJUPYKtz0ONQ6LAKz98cQYPia1Gy9oi4JP4lbsmlTGM1Sg49E0LEnj2MskNX65kPGw90i+9JsGh5xZPeP6Fo1t7l8V5t7bM+6lMc/4n1uNsZADcdEqNp0dQlASB9lwv9fg3umpW1iDBqBbgdtBBZnp7OydNSD28aF3a0jqspAPn6fdX0lxezzsNDmS7GSANWurogSiMd74GA7W9hG/sYGJB6tel+KUzo3Z14I8kK3RT7dSD+qvAl7IcFONsiQyxDOSB4IaVQOQ7wjv4OZDDWJ1zqzlwcoVFg0AD25zVPfnciuszxj6I98zqZy0mTCxkZZPshX/D482T3Xm79QONCXW1s9g8zlyOlJbxChWVIBHiO9VNWAmF/mT9iyIcGB3ohM9RmiA2FDKSad273BNwjz3i66nQUSiZTSZAsfelX91lb7+CQjatCgp3pp9apgkVu6zJj+ovGH2e8wEP7yPSGn+kgI9kRJZ96Msjid9kkJ6iAYRHORpJ7TyLrzSxq806T6cru5cp2ND2nhXxt/QiJbaz1QR+zN2uPxBa9O5QG5F6T77m72Ph9tycHaj/Wh8VGn4E86U=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;
 IPV:NLI; SFV:NSPM; H:SA2PR10MB4474.namprd10.prod.outlook.com; PTR:; CAT:NONE;
 SFS:(396003)(346002)(136003)(376002)(366004)(39860400002)(2906002)(52536014)(122000001)(38100700002)(66446008)(478600001)(76116006)(26005)(66946007)(64756008)(186003)(6916009)(7696005)(66556008)(66476007)(71200400001)(6506007)(44832011)(4326008)(8936002)(5660300002)(316002)(9686003)(54906003)(296002)(86362001)(55016002)(33656002)(4744005);
 DIR:OUT; SFP:1101; 
x-ms-exchange-antispam-messagedata: =?Windows-1252?Q?aTJHTSRm+e/OCqUsps8m5gpNsi05UwVPJyXjeGGX3NbeUN77cD+O4l1t?=
 =?Windows-1252?Q?az7QWaDPZYdFoxzs7TJRshZgo8QpHOnKFLX0wN3FHI3PmxpXpMbIoPX9?=
 =?Windows-1252?Q?2Ulk/CevoXKK1P5rL73SMnOQS1CZjBWm5gBsTQq/UqpwdY+En3rITRye?=
 =?Windows-1252?Q?89kDYGNeK3N7rYJA0RcltzYCLp9r23Bs5R1dUNt4W6tsueeuxUs/T4Y/?=
 =?Windows-1252?Q?T0kE1/3c2kseQWGmPWMk91imfs6r+arVihcibiDeCUw0zZ2SUgxIqUQp?=
 =?Windows-1252?Q?ztxFakMl9jYuM3PggGeTi/Wh+v7MTRtZO5Abv0SXhFRH4sh6okVeyVY9?=
 =?Windows-1252?Q?XinK6sFj3KsBbN7phu29JrAP1uGaqGOvtOaobVwKF+1oBwXUf89rUnOt?=
 =?Windows-1252?Q?5u67QyF8qUWzlyo8+aF7ArRkwwZ5CQtYwLq70IpMQ4k28OXU92mTrfrM?=
 =?Windows-1252?Q?lY75iFbuiYXMIkI2eUvR2UcbMltY41hGYtD2rdWGvIIYDd+WxEcXal2N?=
 =?Windows-1252?Q?aBDQzA9BTGSCD/a32DWi3iOHxPm4wWXUg4I4C901e9Lhm5HddDv9e3i3?=
 =?Windows-1252?Q?T94oGTb9Ew4KVA73Sh3D6wCf84Ic4Eecybm82QmzjbQpP56uVJMvi1F0?=
 =?Windows-1252?Q?DGAOy6HC7cK2JxTS/6WlCaetkhQj5OYOCf2sfUYXkSnsPBMpqG5okyi7?=
 =?Windows-1252?Q?NNMeoZsSeMj2Hyc7YUrEwU7XWHTOXGpKHOkhDjJHZ9wx77xdDi8OK+w/?=
 =?Windows-1252?Q?JoMZrPste4NFK21QXBTb2uhTg2/hV3yp02HHrrzQ0nA6YstxiRSvMpDL?=
 =?Windows-1252?Q?BKAhDZ+HyoxrcNG9Jw5CvcSIgietuHmrPzAqDiYRc8PIo30l5lfAQlWs?=
 =?Windows-1252?Q?ZCNht/3eQ89Xtp5NCrlUMNshuBHvSeihD7y1x2RYQ0iZ8tHnUO4vbvYe?=
 =?Windows-1252?Q?Mv2I2eZ138/3d7VmK8X85JcEHX0HCN8C8jLTCRQZgSNbSyxtwgxFEl0S?=
 =?Windows-1252?Q?VDiW5objmdCUO/6QkRTevBwPnZYMQ/yjuXAk4i2cEVVBb4fz/UwxYZFk?=
 =?Windows-1252?Q?GEIE6nd93l/V95sk2tAORxHr7RvVnPCCwnqEGTK1ytA6asl4BO+n79ft?=
 =?Windows-1252?Q?G9KUGWP1YHMH2lkDdpE4/kGrnE/rppwDG/h66EzREfp0bJvKF9I6inZa?=
 =?Windows-1252?Q?pf+fT/lH/iK6+DoaZtDXmmsTjWZJWSG1TCbtCLiYf2diP2YBKJ6OV+J8?=
 =?Windows-1252?Q?+LLynFxxtmIF3Ewa1jJHiIkHhjMw9vJ7oa4Y77iCUG7Ymr6GN0po8xY8?=
 =?Windows-1252?Q?zH5RXA+mrK3VneB/opHYnbSP/Rz3BN+z/6o+jCuMfzLxukrGb+vySuyG?=
 =?Windows-1252?Q?ElCLEdLWk/pRGJZ5lRe2Sjd4jaCBhMGKnA4=3D?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SA2PR10MB4474.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c4f26092-3f60-4d4d-c9dd-08d9021f14ce
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Apr 2021 04:04:36.5366 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 3cfkLgBxXrXj1Zxwf18Or1y63uTzwM4Qp3pIQf/qT5/HrTtyyZf2EZGPzgMsd8jojvW/vYKq2o0INUKBhrVBfQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR10MB2736
X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9957
 signatures=668683
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0
 bulkscore=0 malwarescore=0
 suspectscore=0 phishscore=0 spamscore=0 mlxlogscore=986 mlxscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104060000
 definitions=main-2104180025
X-Proofpoint-GUID: NuizXY3Y_-O6pYg8p1qbpbmFhPVDk9nA
X-Proofpoint-ORIG-GUID: NuizXY3Y_-O6pYg8p1qbpbmFhPVDk9nA
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 45474
Cc: Gregory Heytings <gregory@HIDDEN>, Juri Linkov <juri@HIDDEN>,
 Dario Gjorgjevski <dario.gjorgjevski@HIDDEN>,
 "45474 <at> debbugs.gnu.org" <45474 <at> debbugs.gnu.org>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

> >> We should think hard before adding yet another argument.  I agree that
> >> the current design is problematic.  Basically, I think that
> >> `minibuffer-completion-table` should be set buffer-locally in the
> >> minibuffer instead of being "set" by dynamic scoping.
> >
> > Apologies for not following this thread, and so
> > possibly misunderstanding what you mean there.
> >
> > But my code depends on `minibuffer-completion-table'
> > being "set" by dynamic scoping.
>=20
> I'm pretty sure there can be such corner cases, but your description
> doesn't make it clear to me why you think setting buffer-locally
> would interact poorly with your use.

I don't know what more to say.  Not being able to
have `minibuffer-completion-table' dynamically
scoped and settable/redefinable as such a variable
would effectively destroy Icicles features that
rely on exactly that ability.  For Icicles, there's
nothing "corner" about this.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45474; Package emacs. Full text available.

Message received at 45474 <at> debbugs.gnu.org:


Received: (at 45474) by debbugs.gnu.org; 18 Apr 2021 03:59:30 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 17 23:59:30 2021
Received: from localhost ([127.0.0.1]:45036 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lXyan-0000Hw-JK
	for submit <at> debbugs.gnu.org; Sat, 17 Apr 2021 23:59:29 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:25560)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1lXyal-0000Hg-RO
 for 45474 <at> debbugs.gnu.org; Sat, 17 Apr 2021 23:59:28 -0400
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
 by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 7A6AE441073;
 Sat, 17 Apr 2021 23:59:22 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 0D178441064;
 Sat, 17 Apr 2021 23:59:21 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1618718361;
 bh=J49gau8Lxd/xB9YEV3eAgMUs+4NLiGNSxU0HZrsEoQk=;
 h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
 b=pjqILzkyjPx2WRmAb0qGBa3TwkqXwXoN/oyKJdA3bjBwqzBVQMoTuZjR27S0EJWCw
 Yhd29z+xIWLlI5JQBDRRnh/GLqPyhUcmFPylIQMAC+pqKI8ByfE8ROSaIOyn9FZkCS
 BWFRq1uhptSpRLK6yT3W/LS3pZsSvuTlTPFk7xrSTc4gk3TckpgaWRjtqejD0/0wAj
 L/3xYeT3xfHH303IrNLtnsQ7ciSBqH2rofu2hOQGbbVWp9FBqyyyLRX8CeaSlATPjM
 5ckCMIpzm277k9QtyJuWbrf7DvNuVcBMQw0KDY9x9CrHd28mRBnZGg1zx6kp+ZXCQS
 6UO0ZX2ktjVeQ==
Received: from alfajor (104-222-126-84.cpe.teksavvy.com [104.222.126.84])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 62D19120330;
 Sat, 17 Apr 2021 23:59:20 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Drew Adams <drew.adams@HIDDEN>
Subject: Re: [External] : bug#45474: Icomplete exhibiting in recursive
 minibuffer when it =?utf-8?Q?shouldn=E2=80=99t?=
Message-ID: <jwv35vo4539.fsf-monnier+emacs@HIDDEN>
References: <fv2zojtus7b0tz.fsf@HIDDEN> <3ed97a9c53e0a5d4fef8@HIDDEN>
 <87fszrz21d.fsf@HIDDEN>
 <3ed97a9c530093aca93d@HIDDEN>
 <7dee3f4235d331cab291@HIDDEN> <87r1jatd34.fsf@HIDDEN>
 <7dee3f423551aaf318cb@HIDDEN> <87im4kzlfm.fsf@HIDDEN>
 <1869622e16546eafd9df@HIDDEN>
 <jwvk0p04mbj.fsf-monnier+emacs@HIDDEN>
 <SA2PR10MB44745ED4108357EC76AA7A6AF34B9@HIDDEN>
Date: Sat, 17 Apr 2021 23:59:19 -0400
In-Reply-To: <SA2PR10MB44745ED4108357EC76AA7A6AF34B9@HIDDEN>
 (Drew Adams's message of "Sat, 17 Apr 2021 23:21:23 +0000")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.103 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 45474
Cc: Gregory Heytings <gregory@HIDDEN>, Juri Linkov <juri@HIDDEN>,
 Dario Gjorgjevski <dario.gjorgjevski@HIDDEN>,
 "45474 <at> debbugs.gnu.org" <45474 <at> debbugs.gnu.org>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

>> We should think hard before adding yet another argument.  I agree that
>> the current design is problematic.  Basically, I think that
>> `minibuffer-completion-table` should be set buffer-locally in the
>> minibuffer instead of being "set" by dynamic scoping.
>
> Apologies for not following this thread, and so
> possibly misunderstanding what you mean there.
>
> But my code depends on `minibuffer-completion-table'
> being "set" by dynamic scoping.

I'm pretty sure there can be such corner cases, but your description
doesn't make it clear to me why you think setting buffer-locally
would interact poorly with your use.


        Stefan





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45474; Package emacs. Full text available.

Message received at 45474 <at> debbugs.gnu.org:


Received: (at 45474) by debbugs.gnu.org; 17 Apr 2021 23:21:32 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 17 19:21:32 2021
Received: from localhost ([127.0.0.1]:44901 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lXuFo-0002D0-1b
	for submit <at> debbugs.gnu.org; Sat, 17 Apr 2021 19:21:32 -0400
Received: from mx0a-00069f02.pphosted.com ([205.220.165.32]:8982)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <drew.adams@HIDDEN>) id 1lXuFk-0002CZ-5e
 for 45474 <at> debbugs.gnu.org; Sat, 17 Apr 2021 19:21:29 -0400
Received: from pps.filterd (m0246629.ppops.net [127.0.0.1])
 by mx0b-00069f02.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id
 13HNHIcJ031144; Sat, 17 Apr 2021 23:21:27 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com;
 h=from : to : cc :
 subject : date : message-id : references : in-reply-to : content-type :
 content-transfer-encoding : mime-version; s=corp-2020-01-29;
 bh=gl1E2E6JPUEV3+IJ1MGAvN2wluJyjk49vevWZOMTDWM=;
 b=H++fULi8KdJihjsakzDBxV3KtulY01fXx93WVl6YMNBOT5BaxZA662Tskf9Mb5ZE3Maw
 M1/odfVRmaCKL/UT4xqoGP5dlLP8kgXoP2uI299eVNIlncHfr/zLRSRRzYxIxXFAh11T
 6OpRmTPo6DNB2K1m95u7SwoerZd1SrCQyZ5dqt1BLC5OODCE2kPCdEGiZDjibGQtV5Kl
 izNOwZ5Emuimk/GlMDecz6ltV7c4ZMWkueK3MzCwAEb8UaHBGqb/oTK40+9kaHiKdK7r
 iSK7caklZWcLUr+0pwUrzkumjMyD1yDGadnK8adD71kZA//ojRmV7PKaJB6eWYFyeotb MQ== 
Received: from oracle.com (aserp3020.oracle.com [141.146.126.70])
 by mx0b-00069f02.pphosted.com with ESMTP id 3806v9r14m-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Sat, 17 Apr 2021 23:21:26 +0000
Received: from aserp3020.oracle.com (aserp3020.oracle.com [127.0.0.1])
 by pps.podrdrct (8.16.0.36/8.16.0.36) with SMTP id 13HNLPgb020636;
 Sat, 17 Apr 2021 23:21:25 GMT
Received: from nam10-bn7-obe.outbound.protection.outlook.com
 (mail-bn7nam10lp2109.outbound.protection.outlook.com [104.47.70.109])
 by aserp3020.oracle.com with ESMTP id 37yqg2ccu1-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Sat, 17 Apr 2021 23:21:25 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=e/GyiF8cj7+JHPBF5Nt1hgb3ja+WiHY0+pZCk2Q7e46oRUyASHx0r5rh7tgVIh/PON7tBDohhx7KxFCmuZqp6jy93wa33Yqo+3kHYUQFHjYLnghI57l1atOAHrGAR6LoBkKG6bWQvzEzhg4i13d/eVS6/urZQ7beVxnWYHABZwQmpwb8kC27QjNXaaFNQHmK3OuAqLOb9f9IMNe2zmNeZCBrJd8cYEG7jaiJwM9tBbWz7Jz8D/wZCAmM4+DYe0elM0pmUDLZ2LQNMOoZXkWbDmVhGwX13vIUiczpxWvyoWieUVDIV6FTCCsbwqn9K2u1xDsKcLRIEZzlnyWh7aiM9Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; 
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=gl1E2E6JPUEV3+IJ1MGAvN2wluJyjk49vevWZOMTDWM=;
 b=a/B7J/OLCrTCa5at2hWt0497M3J369VqR0B63+jj3Er1P8eC1Nfz6shRqh5cMrSy85sgSGXOXeLEbwliiDMF5VgvVX+9HNsLpYX05zGsmNs8PjTzeAlqDySHNRuh2nIowlZMEfy7Hl54/Gh7Ma9E1nu91fvdiahDwQO1GJNclPQABPCSwVgB9oCiFpMqVHgjizUQ05mtszHyZ6Ya0DDV8U+fwfnsmbqM4aC6SwhbzOcHqaIs1xGwdgHrBoK8cilkwNFXGKg7q0gpszLDv116+YKZNB5tDozj1VcGzsdTUoC7GtQZEh5mInAyJBW0Lk2lpi5pXb4zEoqx4EiACpMaag==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com;
 dkim=pass header.d=oracle.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=gl1E2E6JPUEV3+IJ1MGAvN2wluJyjk49vevWZOMTDWM=;
 b=ZyGri0rx6aIudrmeGR2sNXPKrvuILIUFn5smo+NUo0X5y1aWLDWXehx0v+lBJDllrdqxbRBIMviWMxdewHTNBcFffmCdew/yMsAzf9bGTARCar37NPHyC6zVmPoZdEV5aR6PVMiacJ7uvNwD3cMEZf8gfrDlcadnjN11+/cBILM=
Received: from SA2PR10MB4474.namprd10.prod.outlook.com (2603:10b6:806:11b::15)
 by SA2PR10MB4507.namprd10.prod.outlook.com (2603:10b6:806:119::22)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4042.16; Sat, 17 Apr
 2021 23:21:24 +0000
Received: from SA2PR10MB4474.namprd10.prod.outlook.com
 ([fe80::2109:9725:fd4a:6494]) by SA2PR10MB4474.namprd10.prod.outlook.com
 ([fe80::2109:9725:fd4a:6494%6]) with mapi id 15.20.4042.024; Sat, 17 Apr 2021
 23:21:24 +0000
From: Drew Adams <drew.adams@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>, Gregory Heytings
 <gregory@HIDDEN>
Subject: =?Windows-1252?Q?RE:_[External]_:_bug#45474:_Icomplete_exhibiting_in_recu?=
 =?Windows-1252?Q?rsive_minibuffer_when_it_shouldn=92t?=
Thread-Topic: =?Windows-1252?Q?[External]_:_bug#45474:_Icomplete_exhibiting_in_recursiv?=
 =?Windows-1252?Q?e_minibuffer_when_it_shouldn=92t?=
Thread-Index: AQHXM9TnoDvwu5/F0E6n4UylDwwSA6q5T7ew
Date: Sat, 17 Apr 2021 23:21:23 +0000
Message-ID: <SA2PR10MB44745ED4108357EC76AA7A6AF34B9@HIDDEN>
References: <fv2zojtus7b0tz.fsf@HIDDEN> <3ed97a9c53e0a5d4fef8@HIDDEN>
 <87fszrz21d.fsf@HIDDEN>
 <3ed97a9c530093aca93d@HIDDEN>
 <7dee3f4235d331cab291@HIDDEN> <87r1jatd34.fsf@HIDDEN>
 <7dee3f423551aaf318cb@HIDDEN> <87im4kzlfm.fsf@HIDDEN>
 <1869622e16546eafd9df@HIDDEN> <jwvk0p04mbj.fsf-monnier+emacs@HIDDEN>
In-Reply-To: <jwvk0p04mbj.fsf-monnier+emacs@HIDDEN>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: iro.umontreal.ca; dkim=none (message not signed)
 header.d=none;iro.umontreal.ca; dmarc=none action=none
 header.from=oracle.com;
x-originating-ip: [73.170.83.28]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 149f41e8-4166-4bf3-6de3-08d901f78474
x-ms-traffictypediagnostic: SA2PR10MB4507:
x-microsoft-antispam-prvs: <SA2PR10MB45070B7A3916FF539C495769F34B9@HIDDEN>
x-ms-oob-tlc-oobclassifiers: OLM:6790;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 13gH5QBxYTjmTh5aSi2TOjKS4/vYApjijfslwB19b0hZvEh6ArBHimhEaPHj0zxeKQIbcY7qrvtIn9pUAGKQYjZs1NZJnGG0u5G58MljlXgZhVjDq9Xz6pgWvnKDV8x7PPde0W8M1iEadVo7oBJI8uyr1A73WMI+7FRMS+IoJSp31fpOW/2k5Rb3mZKgjkYdF7iRo0f7axChrClqyfelnghxT1rNJOY9wKsAdwzO1+TRz6x8eXAvd2zhFTTZTpa/5In3Abx1qYYt88P4RA0GdIINRa3sp0/ZJ+W0eM+00/b8w7GdXkDDMfQWrsW99meN9QS6bcbDcNk3FwV2zTCh6HuZCrhFJcIvh/mKnZANi9tAc5EoyeF1L/SXaKOdQtmu3WpS+EZa/xUoWrNemveqYefForBVc9STbzf//mFlVxITqRmrTTtavsn4lNZ3ePFjPvSYFsfQnumPz+gphmRJVgCPmwbpxrAKNez20qbB1N90dOqdMdXy6HmPzuuvS8EilbL9oTiUlvnW/BnkXBXr9ZGLn2E9UKWmEOQ/CAFLu4TXoYwrTv1w17azfRsoSc3n8rJd9YJsxC68y8bq0dx8srnWkc4SsyxmZd+CLVbPi+g=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;
 IPV:NLI; SFV:NSPM; H:SA2PR10MB4474.namprd10.prod.outlook.com; PTR:; CAT:NONE;
 SFS:(39860400002)(366004)(396003)(376002)(136003)(346002)(54906003)(4326008)(66446008)(478600001)(66476007)(66946007)(64756008)(2906002)(66556008)(76116006)(8936002)(71200400001)(33656002)(52536014)(186003)(6506007)(38100700002)(7696005)(26005)(9686003)(86362001)(296002)(316002)(44832011)(55016002)(5660300002)(122000001)(110136005)(83380400001)(4744005);
 DIR:OUT; SFP:1101; 
x-ms-exchange-antispam-messagedata: =?Windows-1252?Q?mDup8TUcmS5JhofHlQjrdtJVPjBrcQTU268waQ9IKA1vrCFuSfRwPcyg?=
 =?Windows-1252?Q?t1GHNX0pVRNDUzco8u/0E4AJGVexScghTe7leR0n2w50fyECFKF6fobL?=
 =?Windows-1252?Q?6R5F6nPgD7w6FD3ldWafdwwKAO2BlaIi+RhHLe8umcYqwwAWig+L1ykl?=
 =?Windows-1252?Q?MhRq1pwKh+NqyGshon5lEMCYReewS22F0dIv81QDuPizjEtMA9wapluz?=
 =?Windows-1252?Q?F+PIpstr8LwpC4megGhDEFN2X/Wmvy6tgV0bzgy9D3Fr16LXfgdEpBpX?=
 =?Windows-1252?Q?Mu5PTap2lZ/j7K+0D3LFTOENHqVyLtrJ/SGunajUI28N67y8gf+nz1y3?=
 =?Windows-1252?Q?ebOVLTasnOinR/n42c5TUIyizroRg+IKu4J/AIGuX2yxE3z1JOHEE4XB?=
 =?Windows-1252?Q?/mihyd2364DuuZE6yjvdT+MdDWD+UtWXCkJNOcBzL5v6hux0BnF27jqY?=
 =?Windows-1252?Q?L1RdXyYjg035vjV+jFn32t9rilEDo+blbRkdjsGcGH2pZTIKUnVcRlhD?=
 =?Windows-1252?Q?HWoA6MNWkWgKReXmEEe7X/kKyrSkw9rsR8rHPXIKVmC7xwtMsGqQc/EC?=
 =?Windows-1252?Q?nGRFhQSIStI/VGnuMbfEfOIDpS8Yu/lg3DoOYnjq7jpPOyYWVtnwv9uk?=
 =?Windows-1252?Q?Si4nYQbUmT3TdkeI0uMqL2JSifd0TsSMrbiccPzsF4r5AeTlCBFatHDj?=
 =?Windows-1252?Q?OYrL4KtgyhwI22rZ0J/eGKD5Dz3HHW+UYwp1WWR4Cli8aIN0qejtdhjl?=
 =?Windows-1252?Q?bFA4Zp01rNhaS2cBMtfb8H+mrKtmlIpihXHEyQoOrMPGa0jA/nAlZrb6?=
 =?Windows-1252?Q?WQSwueMBLEpT4gQlGr7ZWLblLttUN/N98NyEHKCpr51rNCYS5dc8DCLs?=
 =?Windows-1252?Q?8MTfVFNxmHDAZu2Ew2jBiyq9wTUWA3Fbzoxsh6sanOr7jU6GgiUxneSO?=
 =?Windows-1252?Q?ZsCYuFbtm6FgqWrFdZy5lY0Nd0y8L+Q/Eu/1lDeoLqBk8Xi83v88Jhnm?=
 =?Windows-1252?Q?RAjrCqQjQ8A6g+8R0p3MZVS6gkL6LsQ9ODz7NVAbLHRsvir/c8JM7me2?=
 =?Windows-1252?Q?TPeLfvaRvTuZIodk6KszNrv8l2/e3BPG5icfjfxC2GEd9+bhkow/7SRY?=
 =?Windows-1252?Q?84jL2amUWzHrQ91mhFOjRJPbvJrHkkN1Fsg9kYtskgMPV6+c90ePwPrQ?=
 =?Windows-1252?Q?8+vssEAT8lX4u2GiYdFc67l6BfG2ZHlPTGAXFzhHApB1GMOpIZaHF9PQ?=
 =?Windows-1252?Q?wnxL6QtpgryLLiDx88dhC3JxqMyrGc21/NfzUiHVw62BSOM70/yu375g?=
 =?Windows-1252?Q?1hm3+Jp43BF2cj0st1jp6CL543uVq31FXNvW7IRhfNjYxia+xoEuplwz?=
 =?Windows-1252?Q?UNxZdTN7IItPS2Tl/cFTpuwLp/NLij1dz3o=3D?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SA2PR10MB4474.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 149f41e8-4166-4bf3-6de3-08d901f78474
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Apr 2021 23:21:23.9731 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: vzIuaxaHKb2Quj2Gc5QlXvtLeAEdGVz4Dpyd4zC3YjTjCrybsBnK8D6SZ5rKQaZos5gzJm+RfM6mzJ+xSMoCZg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA2PR10MB4507
X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9957
 signatures=668683
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=936
 adultscore=0
 suspectscore=0 spamscore=0 phishscore=0 mlxscore=0 bulkscore=0
 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2104060000 definitions=main-2104170166
X-Proofpoint-GUID: AP5cmActEs-oLVNCHGpu7Cw5ebhUL7vq
X-Proofpoint-ORIG-GUID: AP5cmActEs-oLVNCHGpu7Cw5ebhUL7vq
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 45474
Cc: Dario Gjorgjevski <dario.gjorgjevski@HIDDEN>,
 "45474 <at> debbugs.gnu.org" <45474 <at> debbugs.gnu.org>, Juri Linkov <juri@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

> We should think hard before adding yet another argument.  I agree that
> the current design is problematic.  Basically, I think that
> `minibuffer-completion-table` should be set buffer-locally in the
> minibuffer instead of being "set" by dynamic scoping.

Apologies for not following this thread, and so
possibly misunderstanding what you mean there.

But my code depends on `minibuffer-completion-table'
being "set" by dynamic scoping.  I update/change the
table dynamically during the same minibuffer reading.

I do this in several ways, for different purposes
(multiple, very different, purposes).

I also change `minibuffer-completion-predicate',
similarly.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45474; Package emacs. Full text available.

Message received at 45474 <at> debbugs.gnu.org:


Received: (at 45474) by debbugs.gnu.org; 17 Apr 2021 22:16:20 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 17 18:16:20 2021
Received: from localhost ([127.0.0.1]:44848 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lXtEh-0000dk-MQ
	for submit <at> debbugs.gnu.org; Sat, 17 Apr 2021 18:16:20 -0400
Received: from heytings.org ([95.142.160.155]:42360)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <gregory@HIDDEN>) id 1lXtEg-0000da-4p
 for 45474 <at> debbugs.gnu.org; Sat, 17 Apr 2021 18:16:18 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org;
 s=20210101; t=1618697777;
 bh=cvYk5fzKbwy/QTs6azOIx/DAk5YDNAOZMSnK36jPp0w=;
 h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From;
 b=lnHHt7OOEU9rW5COQoWInlvf2Of/yI2MfBNbAxPq3BtugcgBD3ZzMuSxpZ5Ny3dCJ
 bnMKcvOte9sD/GX21XfX7bUYGM6Tpb+tAqRq4CHkpZYDaSPP819jNcZYnNTo9Wnpj5
 2mc7sb/htPC6QUioO7LLRGSZSdvNNZQVzGbWAnmNjBih6jpjulG0eRfdRtwFaky/k2
 fqZX1awX7PYzptI8PXqlM2jhNWSSUc4fQQ4xPz9+tipoxlB4PUhWBf1BsnuG5maNAP
 Bx9X2Wh8JW++bWwOTiv0MeQqXN9pT8H6243bnha20xSBPHx6zmYSjFHcGahrm1YmHt
 UZFzJUssu1ETA==
Date: Sat, 17 Apr 2021 22:16:16 +0000
From: Gregory Heytings <gregory@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
Subject: =?UTF-8?Q?Re=3A_bug#45474=3A_Icomplete_exhibiting_in_recursive?=
 =?UTF-8?Q?_minibuffer_when_it_shouldn=E2=80=99t?=
In-Reply-To: <jwvk0p04mbj.fsf-monnier+emacs@HIDDEN>
Message-ID: <1869622e16dc36c3f2fd@HIDDEN>
References: <fv2zojtus7b0tz.fsf@HIDDEN> <3ed97a9c53e0a5d4fef8@HIDDEN>
 <87fszrz21d.fsf@HIDDEN> <3ed97a9c530093aca93d@HIDDEN>
 <7dee3f4235d331cab291@HIDDEN> <87r1jatd34.fsf@HIDDEN>
 <7dee3f423551aaf318cb@HIDDEN>
 <87im4kzlfm.fsf@HIDDEN> <1869622e16546eafd9df@HIDDEN>
 <jwvk0p04mbj.fsf-monnier+emacs@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="nEwGziF5NE"
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 45474
Cc: Dario Gjorgjevski <dario.gjorgjevski@HIDDEN>, 45474 <at> debbugs.gnu.org,
 Juri Linkov <juri@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)


--nEwGziF5NE
Content-Type: text/plain; charset=us-ascii; format=flowed


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

>> A variant of it would be to add an eight argument to 
>> read-from-minibuffer.  AFAICS it's only the caller that can know 
>> whether the completion backend should be used, IOW, the only thing that 
>> the completion backend can do is to obey the caller.
>
> We should think hard before adding yet another argument.
>

Yes ;-)  Which is why I did not do that.

>
> I agree that the current design is problematic.  Basically, I think that 
> `minibuffer-completion-table` should be set buffer-locally in the 
> minibuffer instead of being "set" by dynamic scoping.
>
> Fixing the problem "right" might call for a significant redesign of 
> `read-from-minibuffer`s API and `completing-read`s implementation.
>
> A quick&dirty workaround for now would be for `completing-read` to set 
> some var alongside `minibuffer-completion-table` which indicates *which* 
> minibuffer this is for (e.g. some minibuffer-depth information). This 
> way `read-from-minibuffer` could distinguish a 
> `minibuffer-completion-table` passed for the current invocation from one 
> passed for the outer invocation and could hence temporarily rebind 
> `minibuffer-completion-table` to nil.
>
> Another approach would be for `completing-read` not to let-bind those 
> vars but instead to use `minibuffer-setup-hook` to set the vars 
> buffer-locally.
>

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.
--nEwGziF5NE
Content-Type: text/x-diff; name=Make-it-possible-to-disable-a-completion-backend-in-.patch
Content-Transfer-Encoding: base64
Content-ID: <1869622e16e521f45f8c@HIDDEN>
Content-Description: 
Content-Disposition: attachment; filename=Make-it-possible-to-disable-a-completion-backend-in-.patch

RnJvbSA5OTA1MGM5NmU3ZmY1MjJhYTFiMTgwOTIwZmFjNzRlOThhMmQ2Yzc5
IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQ0KRnJvbTogR3JlZ29yeSBIZXl0
aW5ncyA8Z3JlZ29yeUBoZXl0aW5ncy5vcmc+DQpEYXRlOiBUaHUsIDE1IEFw
ciAyMDIxIDIzOjUwOjI0ICswMDAwDQpTdWJqZWN0OiBbUEFUQ0hdIE1ha2Ug
aXQgcG9zc2libGUgdG8gZGlzYWJsZSBhIGNvbXBsZXRpb24gYmFja2VuZCBp
biByZWN1cnNpdmUNCiBtaW5pYnVmZmVycw0KDQoqIGxpc3Avc3Vici5lbCAo
cmVhZC1mcm9tLW1pbmlidWZmZXItc2ltcGxlKTogTmV3IG1hY3JvLg0KKGRp
c2FibGUtZm9yLXJlYWQtZnJvbS1taW5pYnVmZmVyLXNpbXBsZSk6IE5ldyBt
YWNyby4NCihyZWFkLWZyb20tbWluaWJ1ZmZlci1zaW1wbGUpOiBOZXcgaW50
ZXJuYWwgdmFyaWFibGUuDQoocmVhZC1udW1iZXIsIHJlYWQtY2hhci1mcm9t
LW1pbmlidWZmZXIsIHktb3Itbi1wKTogVXNlIHRoZSBuZXcgbWFjcm8NCg0K
KiBsaXNwL3NpbXBsZS5lbCAocmVhZC0tZXhwcmVzc2lvbik6IFVzZSB0aGUg
bmV3IG1hY3JvLg0KDQoqIGxpc3AvaWNvbXBsZXRlLmVsIChpY29tcGxldGUt
bWluaWJ1ZmZlci1zZXR1cCk6IFVzZSB0aGUgbmV3IG1hY3JvLg0KLS0tDQog
bGlzcC9pY29tcGxldGUuZWwgfCAgMSArDQogbGlzcC9zaW1wbGUuZWwgICAg
fCAgNiArKystLS0NCiBsaXNwL3N1YnIuZWwgICAgICB8IDI4ICsrKysrKysr
KysrKysrKysrKysrKysrKy0tLS0NCiAzIGZpbGVzIGNoYW5nZWQsIDI4IGlu
c2VydGlvbnMoKyksIDcgZGVsZXRpb25zKC0pDQoNCmRpZmYgLS1naXQgYS9s
aXNwL2ljb21wbGV0ZS5lbCBiL2xpc3AvaWNvbXBsZXRlLmVsDQppbmRleCBk
NWI2Zjc2ZDdiLi43NjMxM2ViOTFkIDEwMDY0NA0KLS0tIGEvbGlzcC9pY29t
cGxldGUuZWwNCisrKyBiL2xpc3AvaWNvbXBsZXRlLmVsDQpAQCAtNDQ2LDYg
KzQ0Niw3IEBAIGljb21wbGV0ZS1zaW1wbGUtY29tcGxldGluZy1wDQogKGRl
ZnVuIGljb21wbGV0ZS1taW5pYnVmZmVyLXNldHVwICgpDQogICAiUnVuIGlu
IG1pbmlidWZmZXIgb24gYWN0aXZhdGlvbiB0byBlc3RhYmxpc2ggaW5jcmVt
ZW50YWwgY29tcGxldGlvbi4NCiBVc3VhbGx5IHJ1biBieSBpbmNsdXNpb24g
aW4gYG1pbmlidWZmZXItc2V0dXAtaG9vaycuIg0KKyAgKGRpc2FibGUtZm9y
LXJlYWQtZnJvbS1taW5pYnVmZmVyLXNpbXBsZSBpY29tcGxldGUtbW9kZSkN
CiAgICh3aGVuIChhbmQgaWNvbXBsZXRlLW1vZGUgKGljb21wbGV0ZS1zaW1w
bGUtY29tcGxldGluZy1wKSkNCiAgICAgKHNldHEtbG9jYWwgaWNvbXBsZXRl
LS1pbml0aWFsLWlucHV0IChpY29tcGxldGUtLWZpZWxkLXN0cmluZykpDQog
ICAgIChzZXRxLWxvY2FsIGNvbXBsZXRpb24tc2hvdy1pbmxpbmUtaGVscCBu
aWwpDQpkaWZmIC0tZ2l0IGEvbGlzcC9zaW1wbGUuZWwgYi9saXNwL3NpbXBs
ZS5lbA0KaW5kZXggOTk5NzU1YTY0Mi4uN2EwOTUzYTkzOSAxMDA2NDQNCi0t
LSBhL2xpc3Avc2ltcGxlLmVsDQorKysgYi9saXNwL3NpbXBsZS5lbA0KQEAg
LTE3NTUsOSArMTc1NSw5IEBAIHJlYWQtLWV4cHJlc3Npb24NCiAgICAgICAg
ICAgKGFkZC1ob29rICdjb21wbGV0aW9uLWF0LXBvaW50LWZ1bmN0aW9ucw0K
ICAgICAgICAgICAgICAgICAgICAgIydlbGlzcC1jb21wbGV0aW9uLWF0LXBv
aW50IG5pbCB0KQ0KICAgICAgICAgICAocnVuLWhvb2tzICdldmFsLWV4cHJl
c3Npb24tbWluaWJ1ZmZlci1zZXR1cC1ob29rKSkNCi0gICAgICAocmVhZC1m
cm9tLW1pbmlidWZmZXIgcHJvbXB0IGluaXRpYWwtY29udGVudHMNCi0gICAg
ICAgICAgICAgICAgICAgICAgICAgICAgcmVhZC1leHByZXNzaW9uLW1hcCB0
DQotICAgICAgICAgICAgICAgICAgICAgICAgICAgICdyZWFkLWV4cHJlc3Np
b24taGlzdG9yeSkpKSkNCisgICAgICAocmVhZC1mcm9tLW1pbmlidWZmZXIt
c2ltcGxlIHByb21wdCBpbml0aWFsLWNvbnRlbnRzDQorICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICByZWFkLWV4cHJlc3Npb24tbWFwIHQN
CisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICdyZWFkLWV4
cHJlc3Npb24taGlzdG9yeSkpKSkNCiANCiAoZGVmdW4gcmVhZC0tZXhwcmVz
c2lvbi10cnktcmVhZCAoKQ0KICAgIlRyeSB0byByZWFkIGFuIEVtYWNzIExp
c3AgZXhwcmVzc2lvbiBpbiB0aGUgbWluaWJ1ZmZlci4NCmRpZmYgLS1naXQg
YS9saXNwL3N1YnIuZWwgYi9saXNwL3N1YnIuZWwNCmluZGV4IGMyYmUyNmEx
NWYuLmQyMjMwZjYwMzQgMTAwNjQ0DQotLS0gYS9saXNwL3N1YnIuZWwNCisr
KyBiL2xpc3Avc3Vici5lbA0KQEAgLTI3OTEsNiArMjc5MSwyNiBAQCByZWFk
LXBhc3N3ZA0KICAgICAgICAgICAgICAgOzsgQW5kIG9mIGNvdXJzZSwgZG9u
J3Qga2VlcCB0aGUgc2Vuc2l0aXZlIGRhdGEgYXJvdW5kLg0KICAgICAgICAg
ICAgICAgKGVyYXNlLWJ1ZmZlcikpKSkpKSkpDQogDQorKGRlZnZhciByZWFk
LWZyb20tbWluaWJ1ZmZlci1zaW1wbGUgbmlsDQorICAiV2hldGhlciBgcmVh
ZC1mcm9tLW1pbmlidWZmZXInIHNob3VsZCBkaXNwbGF5IGNvbXBsZXRpb24g
Y2FuZGlkYXRlcy4iKQ0KKw0KKyhkZWZtYWNybyByZWFkLWZyb20tbWluaWJ1
ZmZlci1zaW1wbGUgKCZyZXN0IGJvZHkpDQorICAiUmVhZCBhIHN0cmluZyBm
cm9tIHRoZSBtaW5pYnVmZmVyIHdpdGhvdXQgY29tcGxldGlvbi4NCitTZXQg
YHJlYWQtZnJvbS1taW5pYnVmZmVyLXNpbXBsZScgdG8gdCwgYW5kIGNhbGwg
YHJlYWQtZnJvbS1taW5pYnVmZmVyJywNCit3aGljaCBzZWUuIg0KKyAgYChw
cm9nbg0KKyAgICAgKHNldHEgcmVhZC1mcm9tLW1pbmlidWZmZXItc2ltcGxl
IHQpDQorICAgICAocmVhZC1mcm9tLW1pbmlidWZmZXIgLEBib2R5KSkpDQor
DQorKGRlZm1hY3JvIGRpc2FibGUtZm9yLXJlYWQtZnJvbS1taW5pYnVmZmVy
LXNpbXBsZSAoY29tcGxldGlvbi1tb2RlKQ0KKyAgIlNldCBDT01QTEVUSU9O
LU1PREUgdG8gbmlsIGZvciBgcmVhZC1mcm9tLW1pbmlidWZmZXItc2ltcGxl
Jy4NCitUaGlzIGlzIG1lYW50IHRvIGJlIHVzZWQgYnkgY29tcGxldGlvbiBi
YWNrZW5kcyB0byBzZXR1cCB0aGUgbWluaWJ1ZmZlcg0KK3RvIGNvbmRpdGlv
bmFsbHkgYWN0aXZhdGUgY29tcGxldGlvbiBpbiBlYWNoIHJlY3Vyc2l2ZSBp
bnZvY2F0aW9uIG9mDQordGhlIG1pbmlidWZmZXIsIHdpdGhvdXQgYWZmZWN0
aW5nIG90aGVyIHJlY3Vyc2l2ZSBpbnZvY2F0aW9ucy4iDQorICBgKHdoZW4g
cmVhZC1mcm9tLW1pbmlidWZmZXItc2ltcGxlDQorICAgICAoc2V0cS1sb2Nh
bCAsY29tcGxldGlvbi1tb2RlIG5pbCkNCisgICAgIChzZXRxIHJlYWQtZnJv
bS1taW5pYnVmZmVyLXNpbXBsZSBuaWwpKSkNCisNCiAoZGVmdmFyIHJlYWQt
bnVtYmVyLWhpc3RvcnkgbmlsDQogICAiVGhlIGRlZmF1bHQgaGlzdG9yeSBm
b3IgdGhlIGByZWFkLW51bWJlcicgZnVuY3Rpb24uIikNCiANCkBAIC0yODEy
LDcgKzI4MzIsNyBAQCByZWFkLW51bWJlcg0KIAkJCQkJcHJvbXB0IHQgdCkp
KSkNCiAgICAgKHdoaWxlDQogCShwcm9nbg0KLQkgIChsZXQgKChzdHIgKHJl
YWQtZnJvbS1taW5pYnVmZmVyDQorCSAgKGxldCAoKHN0ciAocmVhZC1mcm9t
LW1pbmlidWZmZXItc2ltcGxlDQogCQkgICAgICBwcm9tcHQgbmlsIG5pbCBu
aWwgKG9yIGhpc3QgJ3JlYWQtbnVtYmVyLWhpc3RvcnkpDQogCQkgICAgICAo
d2hlbiBkZWZhdWx0DQogCQkJKGlmIChjb25zcCBkZWZhdWx0KQ0KQEAgLTMw
NTIsOCArMzA3Miw4IEBAIHJlYWQtY2hhci1mcm9tLW1pbmlidWZmZXINCiAg
ICAgICAgICA7OyBQcm90ZWN0IHRoaXMtY29tbWFuZCB3aGVuIGNhbGxlZCBm
cm9tIHByZS1jb21tYW5kLWhvb2sgKGJ1ZyM0NTAyOSkNCiAgICAgICAgICAo
dGhpcy1jb21tYW5kIHRoaXMtY29tbWFuZCkNCiAgICAgICAgICAocmVzdWx0
DQotICAgICAgICAgIChyZWFkLWZyb20tbWluaWJ1ZmZlciBwcm9tcHQgbmls
IG1hcCBuaWwNCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChv
ciBoaXN0b3J5ICdlbXB0eS1oaXN0b3J5KSkpDQorICAgICAgICAgIChyZWFk
LWZyb20tbWluaWJ1ZmZlci1zaW1wbGUgcHJvbXB0IG5pbCBtYXAgbmlsDQor
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKG9yIGhp
c3RvcnkgJ2VtcHR5LWhpc3RvcnkpKSkNCiAgICAgICAgICAoY2hhcg0KICAg
ICAgICAgICAoaWYgKD4gKGxlbmd0aCByZXN1bHQpIDApDQogICAgICAgICAg
ICAgICA7OyBXZSBoYXZlIGEgc3RyaW5nICh3aXRoIG9uZSBjaGFyYWN0ZXIp
LCBzbyByZXR1cm4gdGhlIGZpcnN0IG9uZS4NCkBAIC0zMjQ3LDcgKzMyNjcs
NyBAQCB5LW9yLW4tcA0KICAgICAgICAgICAgICAgICAgICAgICAgbWFwKSkN
CiAgICAgICAgICAgICAgOzsgUHJvdGVjdCB0aGlzLWNvbW1hbmQgd2hlbiBj
YWxsZWQgZnJvbSBwcmUtY29tbWFuZC1ob29rIChidWcjNDUwMjkpDQogICAg
ICAgICAgICAgICh0aGlzLWNvbW1hbmQgdGhpcy1jb21tYW5kKQ0KLSAgICAg
ICAgICAgICAoc3RyIChyZWFkLWZyb20tbWluaWJ1ZmZlcg0KKyAgICAgICAg
ICAgICAoc3RyIChyZWFkLWZyb20tbWluaWJ1ZmZlci1zaW1wbGUNCiAgICAg
ICAgICAgICAgICAgICAgcHJvbXB0IG5pbCBrZXltYXAgbmlsDQogICAgICAg
ICAgICAgICAgICAgIChvciB5LW9yLW4tcC1oaXN0b3J5LXZhcmlhYmxlICdl
bXB0eS1oaXN0b3J5KSkpKQ0KICAgICAgICAgKHNldHEgYW5zd2VyIChpZiAo
bWVtYmVyIHN0ciAnKCJ5IiAiWSIpKSAnYWN0ICdza2lwKSkpKSkNCi0tIA0K
Mi4zMC4yDQoNCg==

--nEwGziF5NE--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45474; Package emacs. Full text available.

Message received at 45474 <at> debbugs.gnu.org:


Received: (at 45474) by debbugs.gnu.org; 17 Apr 2021 21:58:43 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 17 17:58:43 2021
Received: from localhost ([127.0.0.1]:44838 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lXsxe-0000C1-Ri
	for submit <at> debbugs.gnu.org; Sat, 17 Apr 2021 17:58:43 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:41097)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1lXsxc-0000Bl-1j
 for 45474 <at> debbugs.gnu.org; Sat, 17 Apr 2021 17:58:41 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 115BA80967;
 Sat, 17 Apr 2021 17:58:34 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 62A7C8033D;
 Sat, 17 Apr 2021 17:58:32 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1618696712;
 bh=mUX+3iJH6fohUtH/AoBA5EGv8aABNjFq6oO7QuA22+4=;
 h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
 b=JFAo7ImoeSUSB4SygYP+apUZqFe9vj63F2lcaQvkast6ALZbRsdqQJdp+k/+isTGc
 xefrFNtNHSsKS3Sw/4Zoi4WolmPDlilV6TpNrY6reekb4zbPU7bi7/TMRhyNcPoOO7
 PRZftU5r2SlVvLpvoFcjQuZEHqNYfQkMH9iuf/v96WNP22AXvsk9yMr8QNx6BPybGW
 N74mKdjq+slKweGcz5VIpuuM1JtfFbCP/lW1tx8JmtLyqjL2mrklYxBhsbB3OX2/Qw
 X2EvF9AXs7sdoc64UZZ+Xz28YlGyiUH7h+N+pKHla5Cg2pqCxaAmRGMFrWsdxp6BYt
 xNkuZdAV/8XCA==
Received: from alfajor (104-222-126-84.cpe.teksavvy.com [104.222.126.84])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 28B7D120151;
 Sat, 17 Apr 2021 17:58:32 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Gregory Heytings <gregory@HIDDEN>
Subject: Re: bug#45474: Icomplete exhibiting in recursive minibuffer when it
 =?utf-8?Q?shouldn=E2=80=99t?=
Message-ID: <jwvk0p04mbj.fsf-monnier+emacs@HIDDEN>
References: <fv2zojtus7b0tz.fsf@HIDDEN> <3ed97a9c53e0a5d4fef8@HIDDEN>
 <87fszrz21d.fsf@HIDDEN>
 <3ed97a9c530093aca93d@HIDDEN>
 <7dee3f4235d331cab291@HIDDEN> <87r1jatd34.fsf@HIDDEN>
 <7dee3f423551aaf318cb@HIDDEN> <87im4kzlfm.fsf@HIDDEN>
 <1869622e16546eafd9df@HIDDEN>
Date: Sat, 17 Apr 2021 17:58:31 -0400
In-Reply-To: <1869622e16546eafd9df@HIDDEN> (Gregory Heytings's message
 of "Sat, 17 Apr 2021 21:35:20 +0000")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.054 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 45474
Cc: Dario Gjorgjevski <dario.gjorgjevski@HIDDEN>, 45474 <at> debbugs.gnu.org,
 Juri Linkov <juri@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> What's wrong with my approach, which disables the completion backend on
> demand?

[ I'm not sure which is "your approach", sorry.  ]

> A variant of it would be to add an eight argument to
> read-from-minibuffer.  AFAICS it's only the caller that can know whether the
> completion backend should be used, IOW, the only thing that the completion
> backend can do is to obey the caller.

We should think hard before adding yet another argument.  I agree that
the current design is problematic.  Basically, I think that
`minibuffer-completion-table` should be set buffer-locally in the
minibuffer instead of being "set" by dynamic scoping.

Fixing the problem "right" might call for a significant redesign of
`read-from-minibuffer`s API and `completing-read`s implementation.

A quick&dirty workaround for now would be for `completing-read` to set
some var alongside `minibuffer-completion-table` which indicates *which*
minibuffer this is for (e.g. some minibuffer-depth information).
This way `read-from-minibuffer` could distinguish
a `minibuffer-completion-table` passed for the current invocation from
one passed for the outer invocation and could hence temporarily rebind
`minibuffer-completion-table` to nil.

Another approach would be for `completing-read` not to let-bind those
vars but instead to use `minibuffer-setup-hook` to set the vars
buffer-locally.

Of course, this ties-in with the discussion about `minibuffer-mode`
where I mentioned that I think the minibuffers should use dedicated
major modes, and that which major mode to use should be indicated via an
argument passed to `read-from-minibuffer`.


        Stefan





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45474; Package emacs. Full text available.

Message received at 45474 <at> debbugs.gnu.org:


Received: (at 45474) by debbugs.gnu.org; 17 Apr 2021 21:35:23 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 17 17:35:23 2021
Received: from localhost ([127.0.0.1]:44818 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lXsb5-00086h-Jf
	for submit <at> debbugs.gnu.org; Sat, 17 Apr 2021 17:35:23 -0400
Received: from heytings.org ([95.142.160.155]:42284)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <gregory@HIDDEN>) id 1lXsb3-00086Z-Uk
 for 45474 <at> debbugs.gnu.org; Sat, 17 Apr 2021 17:35:22 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org;
 s=20210101; t=1618695321;
 bh=TCuoFU+Km3d8h8HBfhm5t+kajxSxDwfMXWSJtdwVI74=;
 h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From;
 b=D0ZdULUrTTzD6XemCdYLtzJ4KAKIicdvFMaQB54WGiT0snaq6adGZK2YJ2XhvXYLQ
 gFCDsJKYKcvh69ZpANCPvEzLo+vAhNQ19Gz3XdkxcMo2HLFusfgwTa+OsESl6Kc/Fe
 nG/lA4vCGfRxr+Ijs35KMH6xHVELud7xGwktIz0oUv6BzkthoQJ60o6g1HvRTpa87r
 3v18sZ0jd9O1MTexOgCkaY0+SJTuGBLYpZsb6DkTymy081qQIsgUzbfSLDHDt+o7q9
 Hi5KDWv/BBLctXet9449o0dTlG6/TGVVo5KGkJECV9fZSZLv9P29cFSrj+3TgMVrK1
 XQ8QtiUNUj1dA==
Date: Sat, 17 Apr 2021 21:35:20 +0000
From: Gregory Heytings <gregory@HIDDEN>
To: Juri Linkov <juri@HIDDEN>
Subject: =?UTF-8?Q?Re=3A_bug#45474=3A_Icomplete_exhibiting_in_recursive?=
 =?UTF-8?Q?_minibuffer_when_it_shouldn=E2=80=99t?=
In-Reply-To: <87im4kzlfm.fsf@HIDDEN>
Message-ID: <1869622e16546eafd9df@HIDDEN>
References: <fv2zojtus7b0tz.fsf@HIDDEN> <3ed97a9c53e0a5d4fef8@HIDDEN>
 <87fszrz21d.fsf@HIDDEN> <3ed97a9c530093aca93d@HIDDEN>
 <7dee3f4235d331cab291@HIDDEN> <87r1jatd34.fsf@HIDDEN>
 <7dee3f423551aaf318cb@HIDDEN>
 <87im4kzlfm.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset=us-ascii
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 45474
Cc: Dario Gjorgjevski <dario.gjorgjevski@HIDDEN>,
 Stefan Monnier <monnier@HIDDEN>, 45474 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)


>
> Oh, I see it's a more fundamental problem:
>

Yes ;-)

>
> 1. completing-read-default let-binds minibuffer-completion-table to a 
> collection before calling read-from-minibuffer;
>
> 2. any nested call to read-from-minibuffer reuses the same value of 
> minibuffer-completion-table, even if it doesn't use completion;
>

Not necessarily, if another completion table has been set during the new 
minibuffer invocation.  That's what happens with C-x C-f followed by C-x 8 
RET.

>
> 3. icomplete checks for minibuffer-completion-table to decide whether to 
> activate icomplete completions in the minibuffer.
>
> This is how non-completion minibuffers get non-nil 
> minibuffer-completion-table.
>
> 'read-string' solves this problem by let-binding 
> minibuffer-completion-table to nil before calling read-from-minibuffer. 
> 'read-number' could do the same. But what about all other calls of 
> 'read-from-minibuffer'?  They all can't be replaced with a new function 
> that will let-bind minibuffer-completion-table to nil.
>

You forgot one element of the problem: completing-read also uses 
read-from-minibuffer.  So you cannot simply use read-from-minibuffer => no 
completions, completing-read => completions.

>
> I have no idea how to fix this.  Maybe Stefan could help (Cc:ed).
>

What's wrong with my approach, which disables the completion backend on 
demand?  A variant of it would be to add an eight argument to 
read-from-minibuffer.  AFAICS it's only the caller that can know whether 
the completion backend should be used, IOW, the only thing that the 
completion backend can do is to obey the caller.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45474; Package emacs. Full text available.

Message received at 45474 <at> debbugs.gnu.org:


Received: (at 45474) by debbugs.gnu.org; 17 Apr 2021 20:53:15 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 17 16:53:15 2021
Received: from localhost ([127.0.0.1]:44769 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lXrwJ-0004xj-CD
	for submit <at> debbugs.gnu.org; Sat, 17 Apr 2021 16:53:15 -0400
Received: from relay1-d.mail.gandi.net ([217.70.183.193]:5427)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <juri@HIDDEN>) id 1lXrwH-0004xT-5q
 for 45474 <at> debbugs.gnu.org; Sat, 17 Apr 2021 16:53:14 -0400
X-Originating-IP: 91.129.102.166
Received: from mail.gandi.net (m91-129-102-166.cust.tele2.ee [91.129.102.166])
 (Authenticated sender: juri@HIDDEN)
 by relay1-d.mail.gandi.net (Postfix) with ESMTPSA id F18D4240006;
 Sat, 17 Apr 2021 20:53:04 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: Gregory Heytings <gregory@HIDDEN>
Subject: Re: bug#45474: Icomplete exhibiting in recursive minibuffer when it
 =?utf-8?Q?shouldn=E2=80=99t?=
Organization: LINKOV.NET
References: <fv2zojtus7b0tz.fsf@HIDDEN> <3ed97a9c53e0a5d4fef8@HIDDEN>
 <87fszrz21d.fsf@HIDDEN>
 <3ed97a9c530093aca93d@HIDDEN>
 <7dee3f4235d331cab291@HIDDEN> <87r1jatd34.fsf@HIDDEN>
 <7dee3f423551aaf318cb@HIDDEN>
Date: Sat, 17 Apr 2021 23:49:01 +0300
In-Reply-To: <7dee3f423551aaf318cb@HIDDEN> (Gregory Heytings's message
 of "Fri, 16 Apr 2021 16:55:56 +0000")
Message-ID: <87im4kzlfm.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 45474
Cc: Dario Gjorgjevski <dario.gjorgjevski@HIDDEN>,
 Stefan Monnier <monnier@HIDDEN>, 45474 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

>> Or maybe simply disable previous icomplete when recursive minibuffer
>> doesn't use completions.
>
> And how would you detect whether a recursive minibuffer expects completions
> or not?

Oh, I see it's a more fundamental problem:

1. completing-read-default let-binds minibuffer-completion-table to a collection
   before calling read-from-minibuffer;
2. any nested call to read-from-minibuffer reuses the same value of
   minibuffer-completion-table, even if it doesn't use completion;
3. icomplete checks for minibuffer-completion-table to decide
   whether to activate icomplete completions in the minibuffer.

This is how non-completion minibuffers get non-nil minibuffer-completion-table.

'read-string' solves this problem by let-binding minibuffer-completion-table
to nil before calling read-from-minibuffer.  'read-number' could do the same.
But what about all other calls of 'read-from-minibuffer'?  They all can't be
replaced with a new function that will let-bind minibuffer-completion-table
to nil.

I have no idea how to fix this.  Maybe Stefan could help (Cc:ed).




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45474; Package emacs. Full text available.

Message received at 45474 <at> debbugs.gnu.org:


Received: (at 45474) by debbugs.gnu.org; 16 Apr 2021 16:56:00 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Apr 16 12:56:00 2021
Received: from localhost ([127.0.0.1]:41584 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lXRlA-0002VP-AG
	for submit <at> debbugs.gnu.org; Fri, 16 Apr 2021 12:56:00 -0400
Received: from heytings.org ([95.142.160.155]:40660)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <gregory@HIDDEN>) id 1lXRl8-0002VE-FS
 for 45474 <at> debbugs.gnu.org; Fri, 16 Apr 2021 12:55:59 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org;
 s=20210101; t=1618592156;
 bh=vAIjjq7wxgZaairOVSNxmEM4p+Y2tBHbyzEucGFKg88=;
 h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From;
 b=j3+ujks84WuO6zMDpOG+7S0yTS4IslgMW7waY3c7LimyCgb/vWrp8nH5XAUVDm123
 hu8E4Ajx12W+7flSqVjYr25xRPq8UIuJLzoRtfQRho2wYhQPi9uMbNNGUVwKdEsqF0
 0wftf9FBTAV5Qcz7YQDUSgQEzEAJY9sRsVmSCj6FAKXMavAs3dfg5g/LvXOMqUaqKM
 uhOCeiQ3xyjzPn20+69wJJkCzayPZJrXsdpJaf/Pr46aEgv3ZEVrQtO2DbdMlndBc2
 U+5NX27QzJsfPabULyXII+Cz7wMWxAZVAAYKk/P0aZw6uQ4JxLCw8F/37hYsWd7xs5
 Ffc4NAet8aJEQ==
Date: Fri, 16 Apr 2021 16:55:56 +0000
From: Gregory Heytings <gregory@HIDDEN>
To: Juri Linkov <juri@HIDDEN>
Subject: =?UTF-8?Q?Re=3A_bug#45474=3A_Icomplete_exhibiting_in_recursive?=
 =?UTF-8?Q?_minibuffer_when_it_shouldn=E2=80=99t?=
In-Reply-To: <87r1jatd34.fsf@HIDDEN>
Message-ID: <7dee3f423551aaf318cb@HIDDEN>
References: <fv2zojtus7b0tz.fsf@HIDDEN> <3ed97a9c53e0a5d4fef8@HIDDEN>
 <87fszrz21d.fsf@HIDDEN> <3ed97a9c530093aca93d@HIDDEN>
 <7dee3f4235d331cab291@HIDDEN> <87r1jatd34.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset=us-ascii
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 45474
Cc: Dario Gjorgjevski <dario.gjorgjevski@HIDDEN>, 45474 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)


>
> I wonder do you really intend to replace all hundreds of 
> read-from-minibuffer calls with read-from-minibuffer-simple? For 
> example, I use 'query-replace' a lot in the completion minibuffer, but 
> it's not fixed.
>

I don't know.  Either we can fix them one by one as bug reports are filed, 
or we can fix them in one shot, possibly with a shorter name (say 
"input-from-minibuffer" or "get-from-minibuffer").  I don't see why it 
would be wrong to do that, or what it could break; the macro is as simple 
as possible.

>
> To be able to narrow the fix to icomplete.el only, it's possible to 
> check the value returned from (minibuffer-depth) before icomplete kicks 
> in, and disable icomplete completions when the value is greater than it 
> was when entered the first minibuffer initially, thus handling recursive 
> minibuffers that don't provide completions.
>

I'm not sure I understand what you mean by this, but AFAICS 
minibuffer-depth cannot be used to determine whether icomplete (or other 
completion backends) should be activated or not.

If you do M-: C-x C-f, you want completions at minibuffer-depth = 1 and 
not at minibuffer-depth = 0; if you do C-x C-f M-:, you want completions 
at minibuffer-depth 0 and not at minibuffer-depth 1; if you do C-x C-f C-x 
8 RET you want completions at minibuffer-depth 0 and at minibuffer-depth 
1; if you do M-: C-x f you do not want completions at minibuffer-depth 0 
nor at minibuffer-depth 1.

>
> Or maybe simply disable previous icomplete when recursive minibuffer 
> doesn't use completions.
>

And how would you detect whether a recursive minibuffer expects 
completions or not?




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45474; Package emacs. Full text available.

Message received at 45474 <at> debbugs.gnu.org:


Received: (at 45474) by debbugs.gnu.org; 16 Apr 2021 16:35:18 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Apr 16 12:35:18 2021
Received: from localhost ([127.0.0.1]:41548 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lXRR8-0001yq-3s
	for submit <at> debbugs.gnu.org; Fri, 16 Apr 2021 12:35:18 -0400
Received: from relay1-d.mail.gandi.net ([217.70.183.193]:49307)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <juri@HIDDEN>) id 1lXRR5-0001yV-Fp
 for 45474 <at> debbugs.gnu.org; Fri, 16 Apr 2021 12:35:16 -0400
X-Originating-IP: 91.129.111.204
Received: from mail.gandi.net (m91-129-111-204.cust.tele2.ee [91.129.111.204])
 (Authenticated sender: juri@HIDDEN)
 by relay1-d.mail.gandi.net (Postfix) with ESMTPSA id AA8DB240007;
 Fri, 16 Apr 2021 16:35:07 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: Gregory Heytings <gregory@HIDDEN>
Subject: Re: bug#45474: Icomplete exhibiting in recursive minibuffer when it
 =?utf-8?Q?shouldn=E2=80=99t?=
Organization: LINKOV.NET
References: <fv2zojtus7b0tz.fsf@HIDDEN> <3ed97a9c53e0a5d4fef8@HIDDEN>
 <87fszrz21d.fsf@HIDDEN>
 <3ed97a9c530093aca93d@HIDDEN>
 <7dee3f4235d331cab291@HIDDEN>
Date: Fri, 16 Apr 2021 19:34:19 +0300
In-Reply-To: <7dee3f4235d331cab291@HIDDEN> (Gregory Heytings's message
 of "Fri, 16 Apr 2021 00:03:18 +0000")
Message-ID: <87r1jatd34.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 45474
Cc: Dario Gjorgjevski <dario.gjorgjevski@HIDDEN>, 45474 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

> @@ -2812,7 +2832,7 @@ read-number
> -	  (let ((str (read-from-minibuffer
> +	  (let ((str (read-from-minibuffer-simple

Thanks for handling 'read-number', I use commands from the 'M-g'
prefix map that read numbers in the completion minibuffer.

> @@ -3052,8 +3072,8 @@ read-char-from-minibuffer
> -          (read-from-minibuffer prompt nil map nil
> -                                (or history 'empty-history)))
> +          (read-from-minibuffer-simple prompt nil map nil
> +                                       (or history 'empty-history)))
>…
> @@ -3247,7 +3267,7 @@ y-or-n-p
> -             (str (read-from-minibuffer
> +             (str (read-from-minibuffer-simple

I wonder do you really intend to replace all hundreds of
read-from-minibuffer calls with read-from-minibuffer-simple?
For example, I use 'query-replace' a lot in the completion minibuffer,
but it's not fixed.

To be able to narrow the fix to icomplete.el only, it's
possible to check the value returned from (minibuffer-depth)
before icomplete kicks in, and disable icomplete completions
when the value is greater than it was when entered the first
minibuffer initially, thus handling recursive minibuffers
that don't provide completions.  Or maybe simply disable
previous icomplete when recursive minibuffer doesn't use
completions.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45474; Package emacs. Full text available.

Message received at 45474 <at> debbugs.gnu.org:


Received: (at 45474) by debbugs.gnu.org; 16 Apr 2021 00:03:23 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Apr 15 20:03:23 2021
Received: from localhost ([127.0.0.1]:39585 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lXBxD-0006T9-76
	for submit <at> debbugs.gnu.org; Thu, 15 Apr 2021 20:03:23 -0400
Received: from heytings.org ([95.142.160.155]:39846)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <gregory@HIDDEN>) id 1lXBxB-0006Sz-4M
 for 45474 <at> debbugs.gnu.org; Thu, 15 Apr 2021 20:03:21 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org;
 s=20210101; t=1618531399;
 bh=JaGBSrDfOrflAq+gqkFtDes+hXvXjrr2H9U6iTHkLnY=;
 h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From;
 b=DOssGs5EbvAOagD5C1eYBeXO0fK9xNSk78Ih1JqCZW1lFSTunDm1qcSF1lNOKA0vc
 qfOnXB1uxkIQubnvii+xYhHJodTIv39GBtfoTNaYkraUQOx7Wh3+5bCU5Xgp+fGKM6
 amZPBCEGNop9CmhPdYG5skZ0+4joAzbi3qKWLyP79dDxOUqzUPZYb1YDT7XoaGDnSb
 vQepu+IBl6BZDkQqMRT6ToF53rEQhVzBLGs0UB8XjyBpf3BtVxIduK3kWhEAmAVdHE
 33ffxNMj5N1MGOeXuFTjgIJYYYcXVKiZccWTEvcJivKHvvHl2iQW3QKoHpC3UXqfn0
 fjpMXldqcTKAg==
Date: Fri, 16 Apr 2021 00:03:18 +0000
From: Gregory Heytings <gregory@HIDDEN>
To: Juri Linkov <juri@HIDDEN>
Subject: =?UTF-8?Q?Re=3A_bug#45474=3A_Icomplete_exhibiting_in_recursive?=
 =?UTF-8?Q?_minibuffer_when_it_shouldn=E2=80=99t?=
In-Reply-To: <3ed97a9c530093aca93d@HIDDEN>
Message-ID: <7dee3f4235d331cab291@HIDDEN>
References: <fv2zojtus7b0tz.fsf@HIDDEN> <3ed97a9c53e0a5d4fef8@HIDDEN>
 <87fszrz21d.fsf@HIDDEN> <3ed97a9c530093aca93d@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="1Lv4e3jSNi"
Content-ID: <7dee3f4235f9838fc7c0@HIDDEN>
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 45474
Cc: Dario Gjorgjevski <dario.gjorgjevski@HIDDEN>, 45474 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)


--1Lv4e3jSNi
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-ID: <7dee3f423509193f482a@HIDDEN>


>
> Anyway, given that you asked for it, here's a more general solution.  I 
> did not check all places where read-from-minibuffer is used, but 
> adapting them is straightforward.
>

And this becomes more elegant, and can be used by other completion 
backends, with two macros.  See attached patch.
--1Lv4e3jSNi
Content-Type: text/x-diff; name=Make-it-possible-to-disable-a-completion-backend-in-.patch
Content-Transfer-Encoding: base64
Content-ID: <7dee3f4235440ab9f19c@HIDDEN>
Content-Description: 
Content-Disposition: attachment; filename=Make-it-possible-to-disable-a-completion-backend-in-.patch

RnJvbSA5OTA1MGM5NmU3ZmY1MjJhYTFiMTgwOTIwZmFjNzRlOThhMmQ2Yzc5
IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQ0KRnJvbTogR3JlZ29yeSBIZXl0
aW5ncyA8Z3JlZ29yeUBoZXl0aW5ncy5vcmc+DQpEYXRlOiBUaHUsIDE1IEFw
ciAyMDIxIDIzOjUwOjI0ICswMDAwDQpTdWJqZWN0OiBbUEFUQ0hdIE1ha2Ug
aXQgcG9zc2libGUgdG8gZGlzYWJsZSBhIGNvbXBsZXRpb24gYmFja2VuZCBp
biByZWN1cnNpdmUNCiBtaW5pYnVmZmVycw0KDQoqIGxpc3Avc3Vici5lbCAo
cmVhZC1mcm9tLW1pbmlidWZmZXItc2ltcGxlKTogTmV3IG1hY3JvLg0KKGRp
c2FibGUtZm9yLXJlYWQtZnJvbS1taW5pYnVmZmVyLXNpbXBsZSk6IE5ldyBt
YWNyby4NCihyZWFkLWZyb20tbWluaWJ1ZmZlci1zaW1wbGUpOiBOZXcgaW50
ZXJuYWwgdmFyaWFibGUuDQoocmVhZC1udW1iZXIsIHJlYWQtY2hhci1mcm9t
LW1pbmlidWZmZXIsIHktb3Itbi1wKTogVXNlIHRoZSBuZXcgbWFjcm8NCg0K
KiBsaXNwL3NpbXBsZS5lbCAocmVhZC0tZXhwcmVzc2lvbik6IFVzZSB0aGUg
bmV3IG1hY3JvLg0KDQoqIGxpc3AvaWNvbXBsZXRlLmVsIChpY29tcGxldGUt
bWluaWJ1ZmZlci1zZXR1cCk6IFVzZSB0aGUgbmV3IG1hY3JvLg0KLS0tDQog
bGlzcC9pY29tcGxldGUuZWwgfCAgMSArDQogbGlzcC9zaW1wbGUuZWwgICAg
fCAgNiArKystLS0NCiBsaXNwL3N1YnIuZWwgICAgICB8IDI4ICsrKysrKysr
KysrKysrKysrKysrKysrKy0tLS0NCiAzIGZpbGVzIGNoYW5nZWQsIDI4IGlu
c2VydGlvbnMoKyksIDcgZGVsZXRpb25zKC0pDQoNCmRpZmYgLS1naXQgYS9s
aXNwL2ljb21wbGV0ZS5lbCBiL2xpc3AvaWNvbXBsZXRlLmVsDQppbmRleCBk
NWI2Zjc2ZDdiLi43NjMxM2ViOTFkIDEwMDY0NA0KLS0tIGEvbGlzcC9pY29t
cGxldGUuZWwNCisrKyBiL2xpc3AvaWNvbXBsZXRlLmVsDQpAQCAtNDQ2LDYg
KzQ0Niw3IEBAIGljb21wbGV0ZS1zaW1wbGUtY29tcGxldGluZy1wDQogKGRl
ZnVuIGljb21wbGV0ZS1taW5pYnVmZmVyLXNldHVwICgpDQogICAiUnVuIGlu
IG1pbmlidWZmZXIgb24gYWN0aXZhdGlvbiB0byBlc3RhYmxpc2ggaW5jcmVt
ZW50YWwgY29tcGxldGlvbi4NCiBVc3VhbGx5IHJ1biBieSBpbmNsdXNpb24g
aW4gYG1pbmlidWZmZXItc2V0dXAtaG9vaycuIg0KKyAgKGRpc2FibGUtZm9y
LXJlYWQtZnJvbS1taW5pYnVmZmVyLXNpbXBsZSBpY29tcGxldGUtbW9kZSkN
CiAgICh3aGVuIChhbmQgaWNvbXBsZXRlLW1vZGUgKGljb21wbGV0ZS1zaW1w
bGUtY29tcGxldGluZy1wKSkNCiAgICAgKHNldHEtbG9jYWwgaWNvbXBsZXRl
LS1pbml0aWFsLWlucHV0IChpY29tcGxldGUtLWZpZWxkLXN0cmluZykpDQog
ICAgIChzZXRxLWxvY2FsIGNvbXBsZXRpb24tc2hvdy1pbmxpbmUtaGVscCBu
aWwpDQpkaWZmIC0tZ2l0IGEvbGlzcC9zaW1wbGUuZWwgYi9saXNwL3NpbXBs
ZS5lbA0KaW5kZXggOTk5NzU1YTY0Mi4uN2EwOTUzYTkzOSAxMDA2NDQNCi0t
LSBhL2xpc3Avc2ltcGxlLmVsDQorKysgYi9saXNwL3NpbXBsZS5lbA0KQEAg
LTE3NTUsOSArMTc1NSw5IEBAIHJlYWQtLWV4cHJlc3Npb24NCiAgICAgICAg
ICAgKGFkZC1ob29rICdjb21wbGV0aW9uLWF0LXBvaW50LWZ1bmN0aW9ucw0K
ICAgICAgICAgICAgICAgICAgICAgIydlbGlzcC1jb21wbGV0aW9uLWF0LXBv
aW50IG5pbCB0KQ0KICAgICAgICAgICAocnVuLWhvb2tzICdldmFsLWV4cHJl
c3Npb24tbWluaWJ1ZmZlci1zZXR1cC1ob29rKSkNCi0gICAgICAocmVhZC1m
cm9tLW1pbmlidWZmZXIgcHJvbXB0IGluaXRpYWwtY29udGVudHMNCi0gICAg
ICAgICAgICAgICAgICAgICAgICAgICAgcmVhZC1leHByZXNzaW9uLW1hcCB0
DQotICAgICAgICAgICAgICAgICAgICAgICAgICAgICdyZWFkLWV4cHJlc3Np
b24taGlzdG9yeSkpKSkNCisgICAgICAocmVhZC1mcm9tLW1pbmlidWZmZXIt
c2ltcGxlIHByb21wdCBpbml0aWFsLWNvbnRlbnRzDQorICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICByZWFkLWV4cHJlc3Npb24tbWFwIHQN
CisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICdyZWFkLWV4
cHJlc3Npb24taGlzdG9yeSkpKSkNCiANCiAoZGVmdW4gcmVhZC0tZXhwcmVz
c2lvbi10cnktcmVhZCAoKQ0KICAgIlRyeSB0byByZWFkIGFuIEVtYWNzIExp
c3AgZXhwcmVzc2lvbiBpbiB0aGUgbWluaWJ1ZmZlci4NCmRpZmYgLS1naXQg
YS9saXNwL3N1YnIuZWwgYi9saXNwL3N1YnIuZWwNCmluZGV4IGMyYmUyNmEx
NWYuLmQyMjMwZjYwMzQgMTAwNjQ0DQotLS0gYS9saXNwL3N1YnIuZWwNCisr
KyBiL2xpc3Avc3Vici5lbA0KQEAgLTI3OTEsNiArMjc5MSwyNiBAQCByZWFk
LXBhc3N3ZA0KICAgICAgICAgICAgICAgOzsgQW5kIG9mIGNvdXJzZSwgZG9u
J3Qga2VlcCB0aGUgc2Vuc2l0aXZlIGRhdGEgYXJvdW5kLg0KICAgICAgICAg
ICAgICAgKGVyYXNlLWJ1ZmZlcikpKSkpKSkpDQogDQorKGRlZnZhciByZWFk
LWZyb20tbWluaWJ1ZmZlci1zaW1wbGUgbmlsDQorICAiV2hldGhlciBgcmVh
ZC1mcm9tLW1pbmlidWZmZXInIHNob3VsZCBkaXNwbGF5IGNvbXBsZXRpb24g
Y2FuZGlkYXRlcy4iKQ0KKw0KKyhkZWZtYWNybyByZWFkLWZyb20tbWluaWJ1
ZmZlci1zaW1wbGUgKCZyZXN0IGJvZHkpDQorICAiUmVhZCBhIHN0cmluZyBm
cm9tIHRoZSBtaW5pYnVmZmVyIHdpdGhvdXQgY29tcGxldGlvbi4NCitTZXQg
YHJlYWQtZnJvbS1taW5pYnVmZmVyLXNpbXBsZScgdG8gdCwgYW5kIGNhbGwg
YHJlYWQtZnJvbS1taW5pYnVmZmVyJywNCit3aGljaCBzZWUuIg0KKyAgYChw
cm9nbg0KKyAgICAgKHNldHEgcmVhZC1mcm9tLW1pbmlidWZmZXItc2ltcGxl
IHQpDQorICAgICAocmVhZC1mcm9tLW1pbmlidWZmZXIgLEBib2R5KSkpDQor
DQorKGRlZm1hY3JvIGRpc2FibGUtZm9yLXJlYWQtZnJvbS1taW5pYnVmZmVy
LXNpbXBsZSAoY29tcGxldGlvbi1tb2RlKQ0KKyAgIlNldCBDT01QTEVUSU9O
LU1PREUgdG8gbmlsIGZvciBgcmVhZC1mcm9tLW1pbmlidWZmZXItc2ltcGxl
Jy4NCitUaGlzIGlzIG1lYW50IHRvIGJlIHVzZWQgYnkgY29tcGxldGlvbiBi
YWNrZW5kcyB0byBzZXR1cCB0aGUgbWluaWJ1ZmZlcg0KK3RvIGNvbmRpdGlv
bmFsbHkgYWN0aXZhdGUgY29tcGxldGlvbiBpbiBlYWNoIHJlY3Vyc2l2ZSBp
bnZvY2F0aW9uIG9mDQordGhlIG1pbmlidWZmZXIsIHdpdGhvdXQgYWZmZWN0
aW5nIG90aGVyIHJlY3Vyc2l2ZSBpbnZvY2F0aW9ucy4iDQorICBgKHdoZW4g
cmVhZC1mcm9tLW1pbmlidWZmZXItc2ltcGxlDQorICAgICAoc2V0cS1sb2Nh
bCAsY29tcGxldGlvbi1tb2RlIG5pbCkNCisgICAgIChzZXRxIHJlYWQtZnJv
bS1taW5pYnVmZmVyLXNpbXBsZSBuaWwpKSkNCisNCiAoZGVmdmFyIHJlYWQt
bnVtYmVyLWhpc3RvcnkgbmlsDQogICAiVGhlIGRlZmF1bHQgaGlzdG9yeSBm
b3IgdGhlIGByZWFkLW51bWJlcicgZnVuY3Rpb24uIikNCiANCkBAIC0yODEy
LDcgKzI4MzIsNyBAQCByZWFkLW51bWJlcg0KIAkJCQkJcHJvbXB0IHQgdCkp
KSkNCiAgICAgKHdoaWxlDQogCShwcm9nbg0KLQkgIChsZXQgKChzdHIgKHJl
YWQtZnJvbS1taW5pYnVmZmVyDQorCSAgKGxldCAoKHN0ciAocmVhZC1mcm9t
LW1pbmlidWZmZXItc2ltcGxlDQogCQkgICAgICBwcm9tcHQgbmlsIG5pbCBu
aWwgKG9yIGhpc3QgJ3JlYWQtbnVtYmVyLWhpc3RvcnkpDQogCQkgICAgICAo
d2hlbiBkZWZhdWx0DQogCQkJKGlmIChjb25zcCBkZWZhdWx0KQ0KQEAgLTMw
NTIsOCArMzA3Miw4IEBAIHJlYWQtY2hhci1mcm9tLW1pbmlidWZmZXINCiAg
ICAgICAgICA7OyBQcm90ZWN0IHRoaXMtY29tbWFuZCB3aGVuIGNhbGxlZCBm
cm9tIHByZS1jb21tYW5kLWhvb2sgKGJ1ZyM0NTAyOSkNCiAgICAgICAgICAo
dGhpcy1jb21tYW5kIHRoaXMtY29tbWFuZCkNCiAgICAgICAgICAocmVzdWx0
DQotICAgICAgICAgIChyZWFkLWZyb20tbWluaWJ1ZmZlciBwcm9tcHQgbmls
IG1hcCBuaWwNCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChv
ciBoaXN0b3J5ICdlbXB0eS1oaXN0b3J5KSkpDQorICAgICAgICAgIChyZWFk
LWZyb20tbWluaWJ1ZmZlci1zaW1wbGUgcHJvbXB0IG5pbCBtYXAgbmlsDQor
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKG9yIGhp
c3RvcnkgJ2VtcHR5LWhpc3RvcnkpKSkNCiAgICAgICAgICAoY2hhcg0KICAg
ICAgICAgICAoaWYgKD4gKGxlbmd0aCByZXN1bHQpIDApDQogICAgICAgICAg
ICAgICA7OyBXZSBoYXZlIGEgc3RyaW5nICh3aXRoIG9uZSBjaGFyYWN0ZXIp
LCBzbyByZXR1cm4gdGhlIGZpcnN0IG9uZS4NCkBAIC0zMjQ3LDcgKzMyNjcs
NyBAQCB5LW9yLW4tcA0KICAgICAgICAgICAgICAgICAgICAgICAgbWFwKSkN
CiAgICAgICAgICAgICAgOzsgUHJvdGVjdCB0aGlzLWNvbW1hbmQgd2hlbiBj
YWxsZWQgZnJvbSBwcmUtY29tbWFuZC1ob29rIChidWcjNDUwMjkpDQogICAg
ICAgICAgICAgICh0aGlzLWNvbW1hbmQgdGhpcy1jb21tYW5kKQ0KLSAgICAg
ICAgICAgICAoc3RyIChyZWFkLWZyb20tbWluaWJ1ZmZlcg0KKyAgICAgICAg
ICAgICAoc3RyIChyZWFkLWZyb20tbWluaWJ1ZmZlci1zaW1wbGUNCiAgICAg
ICAgICAgICAgICAgICAgcHJvbXB0IG5pbCBrZXltYXAgbmlsDQogICAgICAg
ICAgICAgICAgICAgIChvciB5LW9yLW4tcC1oaXN0b3J5LXZhcmlhYmxlICdl
bXB0eS1oaXN0b3J5KSkpKQ0KICAgICAgICAgKHNldHEgYW5zd2VyIChpZiAo
bWVtYmVyIHN0ciAnKCJ5IiAiWSIpKSAnYWN0ICdza2lwKSkpKSkNCi0tIA0K
Mi4zMC4yDQoNCg==

--1Lv4e3jSNi--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45474; Package emacs. Full text available.

Message received at 45474 <at> debbugs.gnu.org:


Received: (at 45474) by debbugs.gnu.org; 15 Apr 2021 22:34:15 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Apr 15 18:34:15 2021
Received: from localhost ([127.0.0.1]:39488 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lXAYx-0004Gm-0d
	for submit <at> debbugs.gnu.org; Thu, 15 Apr 2021 18:34:15 -0400
Received: from heytings.org ([95.142.160.155]:39788)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <gregory@HIDDEN>) id 1lXAYv-0004Ge-80
 for 45474 <at> debbugs.gnu.org; Thu, 15 Apr 2021 18:34:14 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org;
 s=20210101; t=1618526051;
 bh=gMLyagWmiBzg2tWET+ue8OZsp6IZ9KZEKQiLIhmb+bA=;
 h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From;
 b=JfBw2fTDIJx7L+wrXPiP8KyDbfTlNl7DDnOKPXyjRA5YP08AD5z+hGQXJ7YUvniIk
 iPt96K94zGNu+FzuYJMWacZTwFT4mxaf9dRFg7/tyHtXX1GD50a70vgVh0IZG+5Sky
 mzA4oF3y3KaZ4ZvEOSRKLwSn5zS2Ktv7ApcGBhZFhooUowiHgMVBj8Ult/kIYTsd07
 kpnI8Y1FHxakbHEUkpI07rA73xOfF9LnFiSD/RhB0eN5q2NKlJuv8m7FGaNhLjWD8R
 h7Z4s1gYAl0dmdL9IHNcM35cDqyJYq9l6kgf4mjGp2uQOgUrexheZmJi0LthkzRNrb
 sdZubfRmMIp0g==
Date: Thu, 15 Apr 2021 22:34:11 +0000
From: Gregory Heytings <gregory@HIDDEN>
To: Juri Linkov <juri@HIDDEN>
Subject: =?UTF-8?Q?Re=3A_bug#45474=3A_Icomplete_exhibiting_in_recursive?=
 =?UTF-8?Q?_minibuffer_when_it_shouldn=E2=80=99t?=
In-Reply-To: <87fszrz21d.fsf@HIDDEN>
Message-ID: <3ed97a9c530093aca93d@HIDDEN>
References: <fv2zojtus7b0tz.fsf@HIDDEN> <3ed97a9c53e0a5d4fef8@HIDDEN>
 <87fszrz21d.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="RZ51XikxYj"
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 45474
Cc: Dario Gjorgjevski <dario.gjorgjevski@HIDDEN>, 45474 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)


--RZ51XikxYj
Content-Type: text/plain; charset=us-ascii; format=flowed


>>> If the M-: is not in a recursive minibuffer, everything is OK since 
>>> icomplete-simple-completing-p returns nil.
>>
>> Indeed; patch attached.  Ideally this should be done inside 
>> icomplete-minibuffer-setup, but if we did this (by checking 
>> minibuffer-completing-symbol), it would prevent icomplete-mode from 
>> being active in the opposite situation: M-: followed by C-x C-f.
>>
>> @@ -1754,7 +1754,9 @@ read--expression
>>            (set-syntax-table emacs-lisp-mode-syntax-table)
>>            (add-hook 'completion-at-point-functions
>>                      #'elisp-completion-at-point nil t)
>> -          (run-hooks 'eval-expression-minibuffer-setup-hook))
>> +          (run-hooks 'eval-expression-minibuffer-setup-hook)
>> +          ;; if we enter a recursive minibuffer, disable icomplete (bug#45474)
>> +          (setq-local icomplete-mode nil))
>
> Is this really specific only to read--expression? I can reproduce the 
> same issue with any command that doesn't use completion, e.g. C-x C-f 
> C-x f.
>

Indeed, but the bug report was only about read-expression.  It's far more 
annoying to see completion candidates when you want to type a complete 
expression than when you just have to enter a short argument.

Anyway, given that you asked for it, here's a more general solution.  I 
did not check all places where read-from-minibuffer is used, but adapting 
them is straightforward.
--RZ51XikxYj
Content-Type: text/x-diff; name=Make-it-possible-to-disable-icomplete-mode-in-recurs.patch
Content-Transfer-Encoding: base64
Content-ID: <3ed97a9c53d7b5f7e5cb@HIDDEN>
Content-Description: 
Content-Disposition: attachment; filename=Make-it-possible-to-disable-icomplete-mode-in-recurs.patch

RnJvbSA3ZmMzOGYyYTY2ZjU1NDVjMjc2ODM2ZDYyYTdlM2E4NjY5YzNlYjEw
IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQ0KRnJvbTogR3JlZ29yeSBIZXl0
aW5ncyA8Z3JlZ29yeUBoZXl0aW5ncy5vcmc+DQpEYXRlOiBUaHUsIDE1IEFw
ciAyMDIxIDIyOjI3OjA4ICswMDAwDQpTdWJqZWN0OiBbUEFUQ0hdIE1ha2Ug
aXQgcG9zc2libGUgdG8gZGlzYWJsZSBpY29tcGxldGUtbW9kZSBpbiByZWN1
cnNpdmUNCiBtaW5pYnVmZmVycw0KDQoqIGxpc3AvaWNvbXBsZXRlLmVsICht
aW5pYnVmZmVyLWRpc2FibGUtaWNvbXBsZXRlLW1vZGUpOiBOZXcgaW50ZXJu
YWwNCnZhcmlhYmxlLg0KKGljb21wbGV0ZS1taW5pYnVmZmVyLXNldHVwKTog
RGlzYWJsZSBpY29tcGxldGUtbW9kZSB3aGVuDQptaW5pYnVmZmVyLWRpc2Fi
bGUtaWNvbXBsZXRlLW1vZGUgaXMgbm9uLW5pbA0KDQoqIGxpc3Avc3Vici5l
bCAocmVhZC1udW1iZXIsIHJlYWQtY2hhci1mcm9tLW1pbmlidWZmZXIsIHkt
b3Itbi1wKTogVXNlIGl0Lg0KDQoqIGxpc3Avc2ltcGxlLmVsIChyZWFkLS1l
eHByZXNzaW9uKTogVXNlIGl0Lg0KLS0tDQogbGlzcC9pY29tcGxldGUuZWwg
fCAgNSArKysrKw0KIGxpc3Avc2ltcGxlLmVsICAgIHwgIDMgKysrDQogbGlz
cC9zdWJyLmVsICAgICAgfCAxNyArKysrKysrKysrKystLS0tLQ0KIDMgZmls
ZXMgY2hhbmdlZCwgMjAgaW5zZXJ0aW9ucygrKSwgNSBkZWxldGlvbnMoLSkN
Cg0KZGlmZiAtLWdpdCBhL2xpc3AvaWNvbXBsZXRlLmVsIGIvbGlzcC9pY29t
cGxldGUuZWwNCmluZGV4IGQ1YjZmNzZkN2IuLjU1MWI4YmRjNGEgMTAwNjQ0
DQotLS0gYS9saXNwL2ljb21wbGV0ZS5lbA0KKysrIGIvbGlzcC9pY29tcGxl
dGUuZWwNCkBAIC00NDIsMTAgKzQ0MiwxNSBAQCBpY29tcGxldGUtc2ltcGxl
LWNvbXBsZXRpbmctcA0KICAgICAgICAgICAgICAgIChlcSBpY29tcGxldGUt
d2l0aC1jb21wbGV0aW9uLXRhYmxlcyB0KQ0KICAgICAgICAgICAgICAgICht
ZW1iZXIgdGFibGUgaWNvbXBsZXRlLXdpdGgtY29tcGxldGlvbi10YWJsZXMp
KSkpKSkNCiANCisoZGVmdmFyIG1pbmlidWZmZXItZGlzYWJsZS1pY29tcGxl
dGUtbW9kZSBuaWwpDQorDQogOzs7XyA+IGljb21wbGV0ZS1taW5pYnVmZmVy
LXNldHVwICgpDQogKGRlZnVuIGljb21wbGV0ZS1taW5pYnVmZmVyLXNldHVw
ICgpDQogICAiUnVuIGluIG1pbmlidWZmZXIgb24gYWN0aXZhdGlvbiB0byBl
c3RhYmxpc2ggaW5jcmVtZW50YWwgY29tcGxldGlvbi4NCiBVc3VhbGx5IHJ1
biBieSBpbmNsdXNpb24gaW4gYG1pbmlidWZmZXItc2V0dXAtaG9vaycuIg0K
KyAgKHdoZW4gbWluaWJ1ZmZlci1kaXNhYmxlLWljb21wbGV0ZS1tb2RlDQor
ICAgIChzZXRxLWxvY2FsIGljb21wbGV0ZS1tb2RlIG5pbCkNCisgICAgKHNl
dHEgbWluaWJ1ZmZlci1kaXNhYmxlLWljb21wbGV0ZS1tb2RlIG5pbCkpDQog
ICAod2hlbiAoYW5kIGljb21wbGV0ZS1tb2RlIChpY29tcGxldGUtc2ltcGxl
LWNvbXBsZXRpbmctcCkpDQogICAgIChzZXRxLWxvY2FsIGljb21wbGV0ZS0t
aW5pdGlhbC1pbnB1dCAoaWNvbXBsZXRlLS1maWVsZC1zdHJpbmcpKQ0KICAg
ICAoc2V0cS1sb2NhbCBjb21wbGV0aW9uLXNob3ctaW5saW5lLWhlbHAgbmls
KQ0KZGlmZiAtLWdpdCBhL2xpc3Avc2ltcGxlLmVsIGIvbGlzcC9zaW1wbGUu
ZWwNCmluZGV4IDk5OTc1NWE2NDIuLjk2MjZiMzYwNWYgMTAwNjQ0DQotLS0g
YS9saXNwL3NpbXBsZS5lbA0KKysrIGIvbGlzcC9zaW1wbGUuZWwNCkBAIC0x
NzM5LDYgKzE3MzksOCBAQCBldmFsLWV4cHJlc3Npb24tcHJpbnQtZm9ybWF0
DQogKGRlZnZhciBldmFsLWV4cHJlc3Npb24tbWluaWJ1ZmZlci1zZXR1cC1o
b29rIG5pbA0KICAgIkhvb2sgcnVuIGJ5IGBldmFsLWV4cHJlc3Npb24nIHdo
ZW4gZW50ZXJpbmcgdGhlIG1pbmlidWZmZXIuIikNCiANCisoZGVmdmFyIG1p
bmlidWZmZXItZGlzYWJsZS1pY29tcGxldGUtbW9kZSkNCisNCiAoZGVmdW4g
cmVhZC0tZXhwcmVzc2lvbiAocHJvbXB0ICZvcHRpb25hbCBpbml0aWFsLWNv
bnRlbnRzKQ0KICAgIlJlYWQgYW4gRW1hY3MgTGlzcCBleHByZXNzaW9uIGZy
b20gdGhlIG1pbmlidWZmZXIuDQogDQpAQCAtMTc1NSw2ICsxNzU3LDcgQEAg
cmVhZC0tZXhwcmVzc2lvbg0KICAgICAgICAgICAoYWRkLWhvb2sgJ2NvbXBs
ZXRpb24tYXQtcG9pbnQtZnVuY3Rpb25zDQogICAgICAgICAgICAgICAgICAg
ICAjJ2VsaXNwLWNvbXBsZXRpb24tYXQtcG9pbnQgbmlsIHQpDQogICAgICAg
ICAgIChydW4taG9va3MgJ2V2YWwtZXhwcmVzc2lvbi1taW5pYnVmZmVyLXNl
dHVwLWhvb2spKQ0KKyAgICAgIChzZXRxIG1pbmlidWZmZXItZGlzYWJsZS1p
Y29tcGxldGUtbW9kZSB0KQ0KICAgICAgIChyZWFkLWZyb20tbWluaWJ1ZmZl
ciBwcm9tcHQgaW5pdGlhbC1jb250ZW50cw0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICByZWFkLWV4cHJlc3Npb24tbWFwIHQNCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgJ3JlYWQtZXhwcmVzc2lvbi1oaXN0b3J5KSkp
KQ0KZGlmZiAtLWdpdCBhL2xpc3Avc3Vici5lbCBiL2xpc3Avc3Vici5lbA0K
aW5kZXggYzJiZTI2YTE1Zi4uYmMyNWZlMjM0ZiAxMDA2NDQNCi0tLSBhL2xp
c3Avc3Vici5lbA0KKysrIGIvbGlzcC9zdWJyLmVsDQpAQCAtMjc5NCw2ICsy
Nzk0LDggQEAgcmVhZC1wYXNzd2QNCiAoZGVmdmFyIHJlYWQtbnVtYmVyLWhp
c3RvcnkgbmlsDQogICAiVGhlIGRlZmF1bHQgaGlzdG9yeSBmb3IgdGhlIGBy
ZWFkLW51bWJlcicgZnVuY3Rpb24uIikNCiANCisoZGVmdmFyIG1pbmlidWZm
ZXItZGlzYWJsZS1pY29tcGxldGUtbW9kZSkNCisNCiAoZGVmdW4gcmVhZC1u
dW1iZXIgKHByb21wdCAmb3B0aW9uYWwgZGVmYXVsdCBoaXN0KQ0KICAgIlJl
YWQgYSBudW1lcmljIHZhbHVlIGluIHRoZSBtaW5pYnVmZmVyLCBwcm9tcHRp
bmcgd2l0aCBQUk9NUFQuDQogREVGQVVMVCBzcGVjaWZpZXMgYSBkZWZhdWx0
IHZhbHVlIHRvIHJldHVybiBpZiB0aGUgdXNlciBqdXN0IHR5cGVzIFJFVC4N
CkBAIC0yODEyLDYgKzI4MTQsNyBAQCByZWFkLW51bWJlcg0KIAkJCQkJcHJv
bXB0IHQgdCkpKSkNCiAgICAgKHdoaWxlDQogCShwcm9nbg0KKwkgIChzZXRx
IG1pbmlidWZmZXItZGlzYWJsZS1pY29tcGxldGUtbW9kZSB0KQ0KIAkgIChs
ZXQgKChzdHIgKHJlYWQtZnJvbS1taW5pYnVmZmVyDQogCQkgICAgICBwcm9t
cHQgbmlsIG5pbCBuaWwgKG9yIGhpc3QgJ3JlYWQtbnVtYmVyLWhpc3Rvcnkp
DQogCQkgICAgICAod2hlbiBkZWZhdWx0DQpAQCAtMzA1Miw4ICszMDU1LDEw
IEBAIHJlYWQtY2hhci1mcm9tLW1pbmlidWZmZXINCiAgICAgICAgICA7OyBQ
cm90ZWN0IHRoaXMtY29tbWFuZCB3aGVuIGNhbGxlZCBmcm9tIHByZS1jb21t
YW5kLWhvb2sgKGJ1ZyM0NTAyOSkNCiAgICAgICAgICAodGhpcy1jb21tYW5k
IHRoaXMtY29tbWFuZCkNCiAgICAgICAgICAocmVzdWx0DQotICAgICAgICAg
IChyZWFkLWZyb20tbWluaWJ1ZmZlciBwcm9tcHQgbmlsIG1hcCBuaWwNCi0g
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChvciBoaXN0b3J5ICdl
bXB0eS1oaXN0b3J5KSkpDQorICAgICAgICAgIChwcm9nbg0KKyAgICAgICAg
ICAgIChzZXRxIG1pbmlidWZmZXItZGlzYWJsZS1pY29tcGxldGUtbW9kZSB0
KQ0KKyAgICAgICAgICAgIChyZWFkLWZyb20tbWluaWJ1ZmZlciBwcm9tcHQg
bmlsIG1hcCBuaWwNCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgKG9yIGhpc3RvcnkgJ2VtcHR5LWhpc3RvcnkpKSkpDQogICAgICAgICAg
KGNoYXINCiAgICAgICAgICAgKGlmICg+IChsZW5ndGggcmVzdWx0KSAwKQ0K
ICAgICAgICAgICAgICAgOzsgV2UgaGF2ZSBhIHN0cmluZyAod2l0aCBvbmUg
Y2hhcmFjdGVyKSwgc28gcmV0dXJuIHRoZSBmaXJzdCBvbmUuDQpAQCAtMzI0
Nyw5ICszMjUyLDExIEBAIHktb3Itbi1wDQogICAgICAgICAgICAgICAgICAg
ICAgICBtYXApKQ0KICAgICAgICAgICAgICA7OyBQcm90ZWN0IHRoaXMtY29t
bWFuZCB3aGVuIGNhbGxlZCBmcm9tIHByZS1jb21tYW5kLWhvb2sgKGJ1ZyM0
NTAyOSkNCiAgICAgICAgICAgICAgKHRoaXMtY29tbWFuZCB0aGlzLWNvbW1h
bmQpDQotICAgICAgICAgICAgIChzdHIgKHJlYWQtZnJvbS1taW5pYnVmZmVy
DQotICAgICAgICAgICAgICAgICAgIHByb21wdCBuaWwga2V5bWFwIG5pbA0K
LSAgICAgICAgICAgICAgICAgICAob3IgeS1vci1uLXAtaGlzdG9yeS12YXJp
YWJsZSAnZW1wdHktaGlzdG9yeSkpKSkNCisgICAgICAgICAgICAgKHN0ciAo
cHJvZ24NCisgICAgICAgICAgICAgICAgICAgIChzZXRxIG1pbmlidWZmZXIt
ZGlzYWJsZS1pY29tcGxldGUtbW9kZSB0KQ0KKyAgICAgICAgICAgICAgICAg
ICAgKHJlYWQtZnJvbS1taW5pYnVmZmVyDQorICAgICAgICAgICAgICAgICAg
ICAgcHJvbXB0IG5pbCBrZXltYXAgbmlsDQorICAgICAgICAgICAgICAgICAg
ICAgKG9yIHktb3Itbi1wLWhpc3RvcnktdmFyaWFibGUgJ2VtcHR5LWhpc3Rv
cnkpKSkpKQ0KICAgICAgICAgKHNldHEgYW5zd2VyIChpZiAobWVtYmVyIHN0
ciAnKCJ5IiAiWSIpKSAnYWN0ICdza2lwKSkpKSkNCiAgICAgKGxldCAoKHJl
dCAoZXEgYW5zd2VyICdhY3QpKSkNCiAgICAgICAodW5sZXNzIG5vbmludGVy
YWN0aXZlDQotLSANCjIuMzAuMg0KDQo=

--RZ51XikxYj--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45474; Package emacs. Full text available.

Message received at 45474 <at> debbugs.gnu.org:


Received: (at 45474) by debbugs.gnu.org; 15 Apr 2021 21:12:41 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Apr 15 17:12:41 2021
Received: from localhost ([127.0.0.1]:39353 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lX9I1-0002FX-FG
	for submit <at> debbugs.gnu.org; Thu, 15 Apr 2021 17:12:41 -0400
Received: from relay3-d.mail.gandi.net ([217.70.183.195]:36191)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <juri@HIDDEN>) id 1lX9Hy-0002FI-Ha
 for 45474 <at> debbugs.gnu.org; Thu, 15 Apr 2021 17:12:40 -0400
X-Originating-IP: 91.129.111.204
Received: from mail.gandi.net (m91-129-111-204.cust.tele2.ee [91.129.111.204])
 (Authenticated sender: juri@HIDDEN)
 by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id E71E260003;
 Thu, 15 Apr 2021 21:12:30 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: Gregory Heytings <gregory@HIDDEN>
Subject: Re: bug#45474: Icomplete exhibiting in recursive minibuffer when it
 =?utf-8?Q?shouldn=E2=80=99t?=
Organization: LINKOV.NET
References: <fv2zojtus7b0tz.fsf@HIDDEN> <3ed97a9c53e0a5d4fef8@HIDDEN>
Date: Fri, 16 Apr 2021 00:11:10 +0300
In-Reply-To: <3ed97a9c53e0a5d4fef8@HIDDEN> (Gregory Heytings's message
 of "Thu, 15 Apr 2021 17:40:04 +0000")
Message-ID: <87fszrz21d.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 45474
Cc: Dario Gjorgjevski <dario.gjorgjevski@HIDDEN>, 45474 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

>> If the M-: is not in a recursive minibuffer, everything is OK since
>> icomplete-simple-completing-p returns nil.
>
> Indeed; patch attached.  Ideally this should be done inside
> icomplete-minibuffer-setup, but if we did this (by checking
> minibuffer-completing-symbol), it would prevent icomplete-mode from being
> active in the opposite situation: M-: followed by C-x C-f.
>
> @@ -1754,7 +1754,9 @@ read--expression
>            (set-syntax-table emacs-lisp-mode-syntax-table)
>            (add-hook 'completion-at-point-functions
>                      #'elisp-completion-at-point nil t)
> -          (run-hooks 'eval-expression-minibuffer-setup-hook))
> +          (run-hooks 'eval-expression-minibuffer-setup-hook)
> +          ;; if we enter a recursive minibuffer, disable icomplete (bug#45474)
> +          (setq-local icomplete-mode nil))

Is this really specific only to read--expression?
I can reproduce the same issue with any command
that doesn't use completion, e.g. C-x C-f C-x f.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45474; Package emacs. Full text available.

Message received at 45474 <at> debbugs.gnu.org:


Received: (at 45474) by debbugs.gnu.org; 15 Apr 2021 17:40:09 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Apr 15 13:40:09 2021
Received: from localhost ([127.0.0.1]:39131 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lX5yK-0007cM-Ut
	for submit <at> debbugs.gnu.org; Thu, 15 Apr 2021 13:40:09 -0400
Received: from heytings.org ([95.142.160.155]:39528)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <gregory@HIDDEN>) id 1lX5yI-0007cA-Ct
 for 45474 <at> debbugs.gnu.org; Thu, 15 Apr 2021 13:40:07 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org;
 s=20210101; t=1618508404;
 bh=cVc22/ecZkT0OPOQPa4rgMPBLvtNGhOy1Tf/kc7CCuw=;
 h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From;
 b=jkVG1SIdeSD9rlZLZjFCuPNi8la0Ql1ZjS8SgSCttNmg17oVLhY5wMvknSMQN3iw+
 y6Wkul1QwZ8vmYdfnXsKyEp5OJYH+gmG/mFySWd5fHMrt08VezOBTh/j7YCytHWvEe
 LVJabQTSOVHDRuDTr9jH/j1NEX0HxUIOh9P23aq1lQD0UAsVo3+t2/cFEaJjSbRs88
 zL8m9Rtx9pin7cRvSMbe+uqKJTiTIHNgqWLonppm5yl4E7vJ47ZTqoLBxSwaFQP8Kc
 FweQ9VV2IV2LgX+b8pAv37gwh35JfvL7nz7DGSgbbuisjHrI+Lmt6ClaxvNuN6NxS2
 rJFLp0+nQWwoA==
Date: Thu, 15 Apr 2021 17:40:04 +0000
From: Gregory Heytings <gregory@HIDDEN>
To: Dario Gjorgjevski <dario.gjorgjevski@HIDDEN>
Subject: =?UTF-8?Q?Re=3A_bug#45474=3A_Icomplete_exhibiting_in_recursive?=
 =?UTF-8?Q?_minibuffer_when_it_shouldn=E2=80=99t?=
In-Reply-To: <fv2zojtus7b0tz.fsf@HIDDEN>
Message-ID: <3ed97a9c53e0a5d4fef8@HIDDEN>
References: <fv2zojtus7b0tz.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="ptn44ZzFnc"
Content-ID: <3ed97a9c53fe1e78d085@HIDDEN>
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 45474
Cc: 45474 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)


--ptn44ZzFnc
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-ID: <3ed97a9c53f48211d4fd@HIDDEN>


>
> How to reproduce from emacs -Q:
>
>  (setq enable-recursive-minibuffers t)
>  (setq icomplete-show-matches-on-no-input t)
>  M-x icomplete-mode RET
>  C-x C-f
>    [Icomplete now exhibits some filenames in the minibuffer]
>  M-:
>    [Icomplete shouldn=E2=80=99t exhibit anything here but it still
>     exhibits the filenames from the previous step and even
>     allows you to complete them with C-j]
>
> You can replace C-x C-f with other similar commands, e.g., C-x b or M-x.=
=20
> I=E2=80=99m not sure if this bug comes from how Icomplete configures itse=
lf or=20
> the implementation of recursive minibuffers.  It appears that=20
> icomplete-simple-completing-p returns t when the M-: is happening in a=20
> recursive minibuffer, even though it should return nil so that Icomplete=
=20
> doesn=E2=80=99t configure itself.
>
> If the M-: is not in a recursive minibuffer, everything is OK since=20
> icomplete-simple-completing-p returns nil.
>

Indeed; patch attached.  Ideally this should be done inside=20
icomplete-minibuffer-setup, but if we did this (by checking=20
minibuffer-completing-symbol), it would prevent icomplete-mode from being=
=20
active in the opposite situation: M-: followed by C-x C-f.
--ptn44ZzFnc
Content-Type: text/x-diff; name=Disable-icomplete-mode-when-reading-an-Emacs-Lisp-ex.patch
Content-Transfer-Encoding: base64
Content-ID: <3ed97a9c53dc7ca3c6c5@HIDDEN>
Content-Description: 
Content-Disposition: attachment; filename=Disable-icomplete-mode-when-reading-an-Emacs-Lisp-ex.patch

RnJvbSBlNGNiMDcyNzY3MjQ0ODZiZjAxODc1YzI0NjNkZWJmODE3ODRkNTlm
IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQ0KRnJvbTogR3JlZ29yeSBIZXl0
aW5ncyA8Z3JlZ29yeUBoZXl0aW5ncy5vcmc+DQpEYXRlOiBUaHUsIDE1IEFw
ciAyMDIxIDE3OjMzOjM3ICswMDAwDQpTdWJqZWN0OiBbUEFUQ0hdIERpc2Fi
bGUgaWNvbXBsZXRlLW1vZGUgd2hlbiByZWFkaW5nIGFuIEVtYWNzIExpc3Ag
ZXhwcmVzc2lvbg0KDQoqIGxpc3Avc2ltcGxlLmVsIChyZWFkLS1leHByZXNz
aW9uKTogRGlzYWJsZSBpY29tcGxldGUtbW9kZSB3aGVuDQplbnRlcmluZyBh
IHJlY3Vyc2l2ZSBtaW5pYnVmZmVyIHRvIHJlYWQgYW4gRW1hY3MgTGlzcCBl
eHByZXNzaW9uDQooYnVnIzQ1NDc0KS4NCi0tLQ0KIGxpc3Avc2ltcGxlLmVs
IHwgNCArKystDQogMSBmaWxlIGNoYW5nZWQsIDMgaW5zZXJ0aW9ucygrKSwg
MSBkZWxldGlvbigtKQ0KDQpkaWZmIC0tZ2l0IGEvbGlzcC9zaW1wbGUuZWwg
Yi9saXNwL3NpbXBsZS5lbA0KaW5kZXggOTk5NzU1YTY0Mi4uOGY5ZDdhMTk3
YyAxMDA2NDQNCi0tLSBhL2xpc3Avc2ltcGxlLmVsDQorKysgYi9saXNwL3Np
bXBsZS5lbA0KQEAgLTE3NTQsNyArMTc1NCw5IEBAIHJlYWQtLWV4cHJlc3Np
b24NCiAgICAgICAgICAgKHNldC1zeW50YXgtdGFibGUgZW1hY3MtbGlzcC1t
b2RlLXN5bnRheC10YWJsZSkNCiAgICAgICAgICAgKGFkZC1ob29rICdjb21w
bGV0aW9uLWF0LXBvaW50LWZ1bmN0aW9ucw0KICAgICAgICAgICAgICAgICAg
ICAgIydlbGlzcC1jb21wbGV0aW9uLWF0LXBvaW50IG5pbCB0KQ0KLSAgICAg
ICAgICAocnVuLWhvb2tzICdldmFsLWV4cHJlc3Npb24tbWluaWJ1ZmZlci1z
ZXR1cC1ob29rKSkNCisgICAgICAgICAgKHJ1bi1ob29rcyAnZXZhbC1leHBy
ZXNzaW9uLW1pbmlidWZmZXItc2V0dXAtaG9vaykNCisgICAgICAgICAgOzsg
aWYgd2UgZW50ZXIgYSByZWN1cnNpdmUgbWluaWJ1ZmZlciwgZGlzYWJsZSBp
Y29tcGxldGUgKGJ1ZyM0NTQ3NCkNCisgICAgICAgICAgKHNldHEtbG9jYWwg
aWNvbXBsZXRlLW1vZGUgbmlsKSkNCiAgICAgICAocmVhZC1mcm9tLW1pbmli
dWZmZXIgcHJvbXB0IGluaXRpYWwtY29udGVudHMNCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgcmVhZC1leHByZXNzaW9uLW1hcCB0DQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICdyZWFkLWV4cHJlc3Npb24taGlzdG9y
eSkpKSkNCi0tIA0KMi4zMC4yDQoNCg==

--ptn44ZzFnc--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45474; Package emacs. Full text available.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 27 Dec 2020 17:44:48 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Dec 27 12:44:48 2020
Received: from localhost ([127.0.0.1]:33431 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kta64-0007I8-61
	for submit <at> debbugs.gnu.org; Sun, 27 Dec 2020 12:44:48 -0500
Received: from lists.gnu.org ([209.51.188.17]:53004)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <dario.gjorgjevski@HIDDEN>) id 1kta62-0007I0-B4
 for submit <at> debbugs.gnu.org; Sun, 27 Dec 2020 12:44:46 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:51762)
 by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <dario.gjorgjevski@HIDDEN>)
 id 1kta62-0007Od-3B
 for bug-gnu-emacs@HIDDEN; Sun, 27 Dec 2020 12:44:46 -0500
Received: from mail-ej1-x62d.google.com ([2a00:1450:4864:20::62d]:41607)
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.90_1) (envelope-from <dario.gjorgjevski@HIDDEN>)
 id 1kta5z-0000Ur-To
 for bug-gnu-emacs@HIDDEN; Sun, 27 Dec 2020 12:44:45 -0500
Received: by mail-ej1-x62d.google.com with SMTP id ce23so11633482ejb.8
 for <bug-gnu-emacs@HIDDEN>; Sun, 27 Dec 2020 09:44:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:subject:date:message-id:mime-version
 :content-transfer-encoding;
 bh=tyNHBk7QBLgSPde0o0vBGDEG8YxYI98Xiz5p38cfVKQ=;
 b=kAfvJYy5Wj/o6qqpwydTEnq5CIvGmvTPhBa+EYg+mXNQ1qBLc/XOhQlSOLWPYGlRK0
 CRjBlKLnXdtQOL8eh9QH0ApU1vwss1xTuMZg1zdXN7RpEZS1WN0MRuy8uVlu01XS9y+A
 TYNAkcEHhxNQvLo56UNix+UmRIKzenY2IVDl0sDXalPZNHiS5KETTIi88ivHBY95r/z2
 3cMi6YpYoeibyquVkVzv5nhItZfDpK+jYdsZRWPhlYUWDhyBINCti8Kbymeldg5bHi8X
 p2QIKAzXfi7kdM43pjIJS8E3RUBu8HDJxLC6+p99QW41XvEWSvAuiZ71G2+tcSJCXVYV
 57cQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:subject:date:message-id:mime-version
 :content-transfer-encoding;
 bh=tyNHBk7QBLgSPde0o0vBGDEG8YxYI98Xiz5p38cfVKQ=;
 b=VFET69aGz/OUzxLT+3RfVLlPcitTPl3JX4MC0Bwy5ZDpijm+IUc40gEuZ7AXYGoG6P
 edxP4XtlnwYndJ/tlYdMAhK+VsFK7YVVEcG9dQ+sPj5KIiIUE4Guac2+Y06ydsER25vn
 oe/2E9rrV/tiA+pkt81CXLz5IaJ0WFh2Etsn5XL2DMSvXDr8WayJr5GQC1lWTwnyQEZV
 3pEPks7pn7YEL/pc29Kq5URr5RoF/sFfS4BensB0EUr0qpHCstbct0JyKwuRIrqECA1e
 Ftdu4miMYExgm5NyTYlo9dVlBLgwnBCu7k7TrL9+bguwUXAwWduRiU8xsEiVUC28yYCg
 wZIA==
X-Gm-Message-State: AOAM53259RWP2wYxPcEAiFIQC8IcjBBHMY9grKxSTWUpNa69d8SjByqJ
 UXkYEbm0gXkahEYMbaCrroYx6tt4qWc=
X-Google-Smtp-Source: ABdhPJz4EU+5Kpu1qi3RIMRXGT0e7WNHtWVnjJPtFTYQIVj5LDFe4bZRGsmFzvSzcS5WD8U4V4kMqg==
X-Received: by 2002:a17:907:4271:: with SMTP id
 nq1mr38547120ejb.358.1609091081374; 
 Sun, 27 Dec 2020 09:44:41 -0800 (PST)
Received: from ZALANDO-31298 ([79.140.122.235])
 by smtp.gmail.com with ESMTPSA id pg9sm16216827ejb.102.2020.12.27.09.44.40
 for <bug-gnu-emacs@HIDDEN>
 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256);
 Sun, 27 Dec 2020 09:44:40 -0800 (PST)
From: Dario Gjorgjevski <dario.gjorgjevski@HIDDEN>
To: bug-gnu-emacs@HIDDEN
Subject: Icomplete exhibiting in recursive minibuffer when it =?utf-8?Q?sh?=
 =?utf-8?Q?ouldn=E2=80=99t?=
Date: Sun, 27 Dec 2020 18:44:40 +0100
Message-ID: <fv2zojtus7b0tz.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=2a00:1450:4864:20::62d;
 envelope-from=dario.gjorgjevski@HIDDEN; helo=mail-ej1-x62d.google.com
X-Spam_score_int: -20
X-Spam_score: -2.1
X-Spam_bar: --
X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -1.3 (-)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)

How to reproduce from emacs -Q:

  (setq enable-recursive-minibuffers t)
  (setq icomplete-show-matches-on-no-input t)
  M-x icomplete-mode RET
  C-x C-f
    [Icomplete now exhibits some filenames in the minibuffer]
  M-:
    [Icomplete shouldn=E2=80=99t exhibit anything here but it still
     exhibits the filenames from the previous step and even
     allows you to complete them with C-j]

You can replace C-x C-f with other similar commands, e.g., C-x b or M-x.
I=E2=80=99m not sure if this bug comes from how Icomplete configures itself=
 or
the implementation of recursive minibuffers.  It appears that
icomplete-simple-completing-p returns t when the M-: is happening in a
recursive minibuffer, even though it should return nil so that Icomplete
doesn=E2=80=99t configure itself.

If the M-: is not in a recursive minibuffer, everything is OK since
icomplete-simple-completing-p returns nil.

Best regards,
Dario
=20=20
--=20
$ keyserver=3Dhkps://hkps.pool.sks-keyservers.net
$ keyid=3D744A4F0B4F1C9371
$ gpg --keyserver $keyserver --search-keys $keyid




Acknowledgement sent to Dario Gjorgjevski <dario.gjorgjevski@HIDDEN>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs@HIDDEN. Full text available.
Report forwarded to bug-gnu-emacs@HIDDEN:
bug#45474; Package emacs. Full text available.
Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.
Last modified: Mon, 3 May 2021 08:45:02 UTC

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