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 18:13:21 +0000 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; format=flowed; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13288"; 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 20:14:13 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 1la0Je-0003Go-O3 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 23 Apr 2021 20:14:10 +0200 Original-Received: from localhost ([::1]:36694 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1la0Jd-0004mq-R3 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 23 Apr 2021 14:14:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54460) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1la0JW-0004mf-1x for bug-gnu-emacs@gnu.org; Fri, 23 Apr 2021 14:14:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:55483) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1la0JV-0005IV-P8 for bug-gnu-emacs@gnu.org; Fri, 23 Apr 2021 14:14:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1la0JV-0004Dt-K1 for bug-gnu-emacs@gnu.org; Fri, 23 Apr 2021 14:14: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 18:14: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.161920160516175 (code B ref 45474); Fri, 23 Apr 2021 18:14:01 +0000 Original-Received: (at 45474) by debbugs.gnu.org; 23 Apr 2021 18:13:25 +0000 Original-Received: from localhost ([127.0.0.1]:38794 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1la0Iv-0004Cp-0U for submit@debbugs.gnu.org; Fri, 23 Apr 2021 14:13:25 -0400 Original-Received: from heytings.org ([95.142.160.155]:50460) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1la0It-0004Cg-1L for 45474@debbugs.gnu.org; Fri, 23 Apr 2021 14:13:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20210101; t=1619201601; bh=tbUK6WxhyZ2fkXkX69xRBtR1bOKdTbUasaFv+zxkNrw=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=Wbsgr3qpSy8fefyZ/vrn3Rt3C17FClssOGmuobm2X7K7ArIkctH9kUfguvh0SaWqP 8N8jSFuYyMHGDf8BDuEsUK/jDyLI5+tBVlR9d8JSaTmzR+DFF2yPatpekgXwXgrN49 duXayQcNGWRCFIisFFRgDzheQu6I0ebNL2tbegcuiTVseuR28Xriqnf7m00YVmFJPv igzAOebc9J3Dud1jaqr4r7nZdAiNzp8fRY04Q69GEgoc0bCzPQxXv6wxSwFxx7py1w lCy6uZooUt8pTuyvNKfOZ4LwOsHkR7hp7H7N1oQxerQIwcub0EkUG/Zg2CinWA2gfn RzsqybeuGjEDw== 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:204754 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... >> 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. Unless they deliberately use internal-read-from-minibuffer and do some weird things, of course. > > [ 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`, ... ] > I didn't know that ELC files had to be backward-compatible between major releases. 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. >>> 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. > 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.