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 12:14:18 +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="21306"; 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 14:15:39 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 1lYSoV-0005Pk-17 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 19 Apr 2021 14:15:39 +0200 Original-Received: from localhost ([::1]:52124 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lYSoT-0002De-K7 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 19 Apr 2021 08:15:37 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57992) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lYSnu-0002DK-TP for bug-gnu-emacs@gnu.org; Mon, 19 Apr 2021 08:15:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:37073) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lYSnu-0001C9-Lj for bug-gnu-emacs@gnu.org; Mon, 19 Apr 2021 08:15:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lYSnu-0003JW-Fy for bug-gnu-emacs@gnu.org; Mon, 19 Apr 2021 08:15:02 -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 12:15: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.161883446212663 (code B ref 45474); Mon, 19 Apr 2021 12:15:02 +0000 Original-Received: (at 45474) by debbugs.gnu.org; 19 Apr 2021 12:14:22 +0000 Original-Received: from localhost ([127.0.0.1]:48619 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lYSnF-0003IB-MG for submit@debbugs.gnu.org; Mon, 19 Apr 2021 08:14:21 -0400 Original-Received: from heytings.org ([95.142.160.155]:44512) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lYSnE-0003I2-7o for 45474@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== 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:204428 Archived-At: >> 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).