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: Fri, 23 Apr 2021 12:55:02 -0400 Message-ID: References: <87r1jatd34.fsf@mail.linkov.net> <7dee3f423551aaf318cb@heytings.org> <87im4kzlfm.fsf@mail.linkov.net> <1869622e16546eafd9df@heytings.org> <871rb6np5j.fsf@mail.linkov.net> <87lf9cepqw.fsf@mail.linkov.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29529"; 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 Fri Apr 23 19:02:25 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 1lZzCC-0007aK-Ou for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 23 Apr 2021 19:02:25 +0200 Original-Received: from localhost ([::1]:55116 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lZzCB-0007Ab-Pr for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 23 Apr 2021 13:02:23 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36890) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lZz62-00015v-LN for bug-gnu-emacs@gnu.org; Fri, 23 Apr 2021 12:56:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:55385) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lZz62-0008Sx-E6 for bug-gnu-emacs@gnu.org; Fri, 23 Apr 2021 12:56:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lZz62-0002Gp-De for bug-gnu-emacs@gnu.org; Fri, 23 Apr 2021 12:56: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: Fri, 23 Apr 2021 16:56: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.16191969138663 (code B ref 45474); Fri, 23 Apr 2021 16:56:02 +0000 Original-Received: (at 45474) by debbugs.gnu.org; 23 Apr 2021 16:55:13 +0000 Original-Received: from localhost ([127.0.0.1]:38698 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lZz5E-0002Fe-KL for submit@debbugs.gnu.org; Fri, 23 Apr 2021 12:55:12 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:16598) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lZz5D-0002FO-F9 for 45474@debbugs.gnu.org; Fri, 23 Apr 2021 12:55:11 -0400 Original-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) Original-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== Original-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) In-Reply-To: (Gregory Heytings's message of "Fri, 23 Apr 2021 15:58:51 +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:204751 Archived-At: > 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