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: Fri, 23 Apr 2021 21:36:31 +0000 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; format=flowed; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19106"; 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 Fri Apr 23 23:37:09 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 1la3U5-0004ek-Le for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 23 Apr 2021 23:37:09 +0200 Original-Received: from localhost ([::1]:45890 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1la3U4-0003Mh-J2 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 23 Apr 2021 17:37:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36202) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1la3Ty-0003MO-0K for bug-gnu-emacs@gnu.org; Fri, 23 Apr 2021 17:37:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:55746) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1la3Tx-0000W6-Oy for bug-gnu-emacs@gnu.org; Fri, 23 Apr 2021 17:37:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1la3Tx-0000mV-Ly for bug-gnu-emacs@gnu.org; Fri, 23 Apr 2021 17:37:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Gregory Heytings Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 23 Apr 2021 21:37: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.16192137942970 (code B ref 45474); Fri, 23 Apr 2021 21:37:01 +0000 Original-Received: (at 45474) by debbugs.gnu.org; 23 Apr 2021 21:36:34 +0000 Original-Received: from localhost ([127.0.0.1]:39059 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1la3TW-0000lp-G1 for submit@debbugs.gnu.org; Fri, 23 Apr 2021 17:36:34 -0400 Original-Received: from heytings.org ([95.142.160.155]:50650) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1la3TU-0000lh-QH for 45474@debbugs.gnu.org; Fri, 23 Apr 2021 17:36:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20210101; t=1619213791; bh=pHWfvH71cUWL5NAYxpCwWvmMqVxiUsWERqBjqU4Sy7c=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=XhU9etqiEvCXv1wXdKmt3PWjrHkvqLNGjTV3iSTPM0Veep7wQOV7obzeC16SeLQHM eUvGRWTIjJXY/seXhVgoQziHLNpHUndEt3yiRSSXR+AbDkbe+/J3Oohk/xReKYip9P 21Y8dupwpruikGVcTtA5HYy7nt93JGrrKq7CKQbjkgJWF9XgCoSDT38KpMGbJfee00 rAbI3A0KKBSm66Q30BK4VhAFTa5KC+34x0aWrcJ3XD4sXwMKXpkk6ZYhScpBOaGAln Gp63M2Xz8Dk5QQ8BHmU4saniopn1Q8lkYYgn4Mrj4EWS1AwB/0QjsrbkcO/fJ2aWPG rGUTs9EMFioUA== 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:204763 Archived-At: >> 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 believe that creating an optional behavior that is easy to use, and stating that that behavior will become mandatory in the next major Emacs release, is a stronger incentive. >> 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`. > Aren't these problems orthogonal to the problem at hand? It seems to me that this is not different from the traditional way of passing arguments to a function; of course something unexpected can happen when they are evaluated, before the function is entered, but that's something outside the responsibility of the function. My aim here was to (help to) fix the nine years old "FIXME: `minibuffer-completion-table' should be buffer-local instead." What would you do to fix it, in an ideal world in which backward compatibility is not an issue?