From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#45474: Icomplete exhibiting in recursive minibuffer when it =?UTF-8?Q?shouldn=E2=80=99t?= Date: Sun, 18 Apr 2021 21:26:13 -0400 Message-ID: References: <3ed97a9c53e0a5d4fef8@heytings.org> <87fszrz21d.fsf@mail.linkov.net> <3ed97a9c530093aca93d@heytings.org> <7dee3f4235d331cab291@heytings.org> <87r1jatd34.fsf@mail.linkov.net> <7dee3f423551aaf318cb@heytings.org> <87im4kzlfm.fsf@mail.linkov.net> <1869622e16546eafd9df@heytings.org> <1869622e16dc36c3f2fd@heytings.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15384"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Dario Gjorgjevski , 45474@debbugs.gnu.org, Juri Linkov To: Gregory Heytings Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Apr 19 03:27:14 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 1lYIgz-0003qD-Hu for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 19 Apr 2021 03:27:13 +0200 Original-Received: from localhost ([::1]:43398 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lYIgx-0004YI-Nh for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 18 Apr 2021 21:27:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34576) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lYIgo-0004Y7-B3 for bug-gnu-emacs@gnu.org; Sun, 18 Apr 2021 21:27:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:36523) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lYIgo-0003z2-3s for bug-gnu-emacs@gnu.org; Sun, 18 Apr 2021 21:27:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lYIgo-0001Wd-0O for bug-gnu-emacs@gnu.org; Sun, 18 Apr 2021 21:27:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 19 Apr 2021 01:27: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.16187955865818 (code B ref 45474); Mon, 19 Apr 2021 01:27:01 +0000 Original-Received: (at 45474) by debbugs.gnu.org; 19 Apr 2021 01:26:26 +0000 Original-Received: from localhost ([127.0.0.1]:48069 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lYIgD-0001Vm-C9 for submit@debbugs.gnu.org; Sun, 18 Apr 2021 21:26:25 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:24426) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lYIgB-0001VY-1g for 45474@debbugs.gnu.org; Sun, 18 Apr 2021 21:26:23 -0400 Original-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) Original-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== Original-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) In-Reply-To: (Gregory Heytings's message of "Sun, 18 Apr 2021 22:23:46 +0000") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:204418 Archived-At: >>> 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