From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gregory Heytings Newsgroups: gmane.emacs.bugs Subject: bug#45474: Icomplete exhibiting in recursive minibuffer when it =?UTF-8?Q?shouldn=E2=80=99t?= Date: Mon, 19 Apr 2021 20:20:04 +0000 Message-ID: References: <3ed97a9c53e0a5d4fef8@heytings.org> <87fszrz21d.fsf@mail.linkov.net> <3ed97a9c530093aca93d@heytings.org> <7dee3f4235d331cab291@heytings.org> <87r1jatd34.fsf@mail.linkov.net> <7dee3f423551aaf318cb@heytings.org> <87im4kzlfm.fsf@mail.linkov.net> <1869622e16546eafd9df@heytings.org> <1869622e16dc36c3f2fd@heytings.org> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23432"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Dario Gjorgjevski , 45474@debbugs.gnu.org, Juri Linkov To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Apr 19 22:26:51 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lYaTr-0005z3-9I for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 19 Apr 2021 22:26:51 +0200 Original-Received: from localhost ([::1]:59794 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lYaTq-0002C8-2R for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 19 Apr 2021 16:26:50 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33094) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lYaOF-0004PS-0V for bug-gnu-emacs@gnu.org; Mon, 19 Apr 2021 16:21:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:40643) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lYaOD-0001TH-O1 for bug-gnu-emacs@gnu.org; Mon, 19 Apr 2021 16:21:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lYaOD-0002TQ-K5 for bug-gnu-emacs@gnu.org; Mon, 19 Apr 2021 16:21:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Gregory Heytings Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 19 Apr 2021 20:21:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 45474 X-GNU-PR-Package: emacs Original-Received: via spool by 45474-submit@debbugs.gnu.org id=B45474.16188636089421 (code B ref 45474); Mon, 19 Apr 2021 20:21:01 +0000 Original-Received: (at 45474) by debbugs.gnu.org; 19 Apr 2021 20:20:08 +0000 Original-Received: from localhost ([127.0.0.1]:52189 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lYaNM-0002Rr-7S for submit@debbugs.gnu.org; Mon, 19 Apr 2021 16:20:08 -0400 Original-Received: from heytings.org ([95.142.160.155]:45196) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lYaNK-0002Rj-Gt for 45474@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== In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:204505 Archived-At: > > 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.