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 16:24:34 -0400 Message-ID: References: <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="2778"; 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 22:25:12 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 1la2MR-0000Zg-0M for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 23 Apr 2021 22:25:11 +0200 Original-Received: from localhost ([::1]:54068 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1la2MP-0007uG-M3 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 23 Apr 2021 16:25:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50948) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1la2MI-0007ty-Pu for bug-gnu-emacs@gnu.org; Fri, 23 Apr 2021 16:25:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:55654) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1la2MI-00071e-Fp for bug-gnu-emacs@gnu.org; Fri, 23 Apr 2021 16:25:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1la2MI-0007TQ-Cp for bug-gnu-emacs@gnu.org; Fri, 23 Apr 2021 16:25: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 20:25: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.161920949028707 (code B ref 45474); Fri, 23 Apr 2021 20:25:02 +0000 Original-Received: (at 45474) by debbugs.gnu.org; 23 Apr 2021 20:24:50 +0000 Original-Received: from localhost ([127.0.0.1]:38967 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1la2M5-0007Sx-ST for submit@debbugs.gnu.org; Fri, 23 Apr 2021 16:24:50 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:23339) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1la2M4-0007Sl-Dm for 45474@debbugs.gnu.org; Fri, 23 Apr 2021 16:24:48 -0400 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id E0B4080931; Fri, 23 Apr 2021 16:24:42 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 8A775801AB; Fri, 23 Apr 2021 16:24:36 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1619209476; bh=7boCtwFg/6BDejRL2HffxqoFAQWaye2Bgtn36VjlbZU=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=lv0dLKPXRyEwKy8cI7MRJZhwjHOyWKZaHrLvMqThRLjdEL4WWLGSMCsA4j/bMybcG BM07GJD2d1K9064OG1rxuofpDeRVL6j71GU/luhbjZm/Mnyd9RW3FP32A+UHwzIv+s rNMXrfnsDDCGB2ExDM/2SCAu+BsO8nv/n95pLN/gn9hzebNDgkEqWepJs/MdRpivnV iiYSOtrihIo2ly/WB3j0ly477PfsjGXrrg7k77b8jwRDwqCuC8MigxWsFP2Am5SRmN LS/wyUN7KCcX80aF/pScLgkpxPag012anT7IAKO730ZdPr+2Mc8MevBN917a7WBTR5 442Cznt/GL8nQ== Original-Received: from alfajor (104-222-126-84.cpe.teksavvy.com [104.222.126.84]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 47B1312026E; Fri, 23 Apr 2021 16:24:36 -0400 (EDT) In-Reply-To: (Gregory Heytings's message of "Fri, 23 Apr 2021 18:13:21 +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:204757 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). > Indeed, but... it doesn't help/incite them to move forward in the "right" > direction, to finally have what has been on wishlist for quite a long time: > to have buffer-local minibuffer-completion-* elements... It helps by showing how to do it. I haven't seen any proposal here which helps further than that (except maybe for some proposals which might break such code, thus inciting them to use a better approach ;-). >>> 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`. > I see. But when the let-bindings are in a macro the caller doesn't have to > care with them, and they are indeed happening as close as possible to > internal-read-from-minibuffer. AFAICT you're talking about the let-bindings of `minibuffer-local-*` whereas the problematic let-bindings are those of `minibuffer-completion-*` and those are outside of `read-from-minibuffer`. > I didn't know that ELC files had to be backward-compatible between major > releases. We don't guarantee such compatibility 100%, but we do our best, and it's pretty easy to avoid the problem here, so turning `read-from-minibuffer` into a macro would not qualify as "do our best", I think. > That being said, my preference would be to have the whole dancing > happening at the C level (inside read_from_minibuffer and/or read_minibuf), > which would solve that problem/these problems. The [SOMETHINGn] are still outside of `read-from-minibuffer` so the implementation of `read-from-minibuffer` doesn't affect the problem, really. > No worries ;-) Now I see what you mean, and I do not see where you see > a potential problem there: whether the minibuffer-completion-* elements > become buffer-local depends on the minibuffer-local-completion > variable. When it is nil (the default), they do not become buffer-local, and > the behavior of read-from-minibuffer is the same as earlier. This gives > external package plenty of time to adapt their code to the future > minibuffer-local-completion = t situation. No, I'm talking about external packages for example those working like `icomplete-mode`: they don't change the code which sets `minibuffer-completion-table`, they just look for the completion table in `minibuffer-completion-table`. Currently such packages can access `minibuffer-completion-table` from any buffer. With our patches this is not the case any more: they can only access it from the minibuffer. So far I haven't found such code, tho, so maybe the risk of breakage is actually much less severe than I imagined. In any case, this is risk is the same for both patches. Stefan