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: Sat, 17 Apr 2021 17:58:31 -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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5636"; 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 Sat Apr 17 23:59:10 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 1lXsy6-0001Ln-ER for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 17 Apr 2021 23:59:10 +0200 Original-Received: from localhost ([::1]:54098 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lXsy5-0006Bh-GM for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 17 Apr 2021 17:59:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56718) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lXsxy-0006BP-Sw for bug-gnu-emacs@gnu.org; Sat, 17 Apr 2021 17:59:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:33292) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lXsxy-00076F-Ly for bug-gnu-emacs@gnu.org; Sat, 17 Apr 2021 17:59:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lXsxy-0000CZ-IY for bug-gnu-emacs@gnu.org; Sat, 17 Apr 2021 17:59: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: Sat, 17 Apr 2021 21:59:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 45474 X-GNU-PR-Package: emacs Original-Received: via spool by 45474-submit@debbugs.gnu.org id=B45474.1618696723749 (code B ref 45474); Sat, 17 Apr 2021 21:59:02 +0000 Original-Received: (at 45474) by debbugs.gnu.org; 17 Apr 2021 21:58:43 +0000 Original-Received: from localhost ([127.0.0.1]:44838 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lXsxe-0000C1-Ri for submit@debbugs.gnu.org; Sat, 17 Apr 2021 17:58:43 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:41097) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lXsxc-0000Bl-1j for 45474@debbugs.gnu.org; Sat, 17 Apr 2021 17:58:41 -0400 Original-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) Original-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== Original-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) In-Reply-To: <1869622e16546eafd9df@heytings.org> (Gregory Heytings's message of "Sat, 17 Apr 2021 21:35:20 +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:204274 Archived-At: > 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