From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Spencer Baugh via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#74019: [PATCH] Optionally preserve selected candidate across *Completions* update Date: Mon, 28 Oct 2024 10:08:27 -0400 Message-ID: References: <86a5erbbwl.fsf@gnu.org> Reply-To: Spencer Baugh Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32634"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Eli Zaretskii , Andrea Corallo , Stefan Kangas , 74019@debbugs.gnu.org, juri@linkov.net To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Oct 28 15:09:52 2024 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 1t5QRL-0008I4-6W for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 28 Oct 2024 15:09:51 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1t5QQy-0003dG-B8; Mon, 28 Oct 2024 10:09:28 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1t5QQw-0003d2-I2 for bug-gnu-emacs@gnu.org; Mon, 28 Oct 2024 10:09:26 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1t5QQw-0001U2-A0 for bug-gnu-emacs@gnu.org; Mon, 28 Oct 2024 10:09:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=MIME-Version:Date:References:In-Reply-To:From:To:Subject; bh=WD3+MqgsteuU1QiCfp0BNZIwej1RfzhSe6XsJ4J7918=; b=O14DzkA8BDrqd97KJg3Iej8TJcrie+xuX2rya9mvSolWi79E1b1nuTEfMvKZQNis2+h8UsAdR2Qj194CFgFwfqOzrTn77d95UDydbtIB8ZpOwTc5krJKflkdrLtohLmuqhGprc0PSUI5ACRUoZ5KOv4BHpkbckcHZ8FRn/i6OF46zlFrDWbgyvywLQpllktl3BgA9Cn60aISXvm9obpS3u14QMWSzE25jjrHzhYsBoxyxVsPssHvDEDfnpzlXe6XgQEeuKZeVsNBa1MTgzNC0IXAZpzdUMoFsozQHcqpcQwe7oSQWtzViqPD3BzCBTNgd1vEqUjjm31GCrNKmlIKkg==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1t5QRW-0002Ot-7j for bug-gnu-emacs@gnu.org; Mon, 28 Oct 2024 10:10:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Spencer Baugh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 28 Oct 2024 14:10:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74019 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 74019-submit@debbugs.gnu.org id=B74019.17301245529154 (code B ref 74019); Mon, 28 Oct 2024 14:10:02 +0000 Original-Received: (at 74019) by debbugs.gnu.org; 28 Oct 2024 14:09:12 +0000 Original-Received: from localhost ([127.0.0.1]:54256 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t5QQh-0002Na-MD for submit@debbugs.gnu.org; Mon, 28 Oct 2024 10:09:12 -0400 Original-Received: from mxout6.mail.janestreet.com ([64.215.233.21]:59987) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t5QQe-0002NK-VZ for 74019@debbugs.gnu.org; Mon, 28 Oct 2024 10:09:09 -0400 In-Reply-To: (Stefan Monnier's message of "Sat, 26 Oct 2024 10:59:18 -0400") DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=waixah; t=1730124507; bh=WD3+MqgsteuU1QiCfp0BNZIwej1RfzhSe6XsJ4J7918=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=CjBT7cv8Fo0PewWfWeKuI/kYCQeNzhqMxBKmYrDotEJsnoqcOLk6342YvXhTTXRzR 2Ltf8hZlt3StCZgAK6w4L1cEtPLvAercv98u2eGpHevDp6F4P4dtiSgDiGODnYSrpX kVjSYE61EkM23azlXf8jtuwcweaccJTMDDBm1rAhqXTm8FbMM2JIGf22V30FyB4IGc 3AgYQL72QS6e24ehg0Mmqr1ZqQuT+0Oq2MICs0m7Wb80CbgYfteCS/OWlZuUc9rWGR XCebCpxImSlBbl6+8bP9GKXQI8hDP819qNPRCCj3oLJxSnO3m5JH9gHq1UkX6zgrxA pBWfJtFdGRR+Q== 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:294424 Archived-At: Stefan Monnier writes: >> Shouldn't we stop complicating the completion machinery at some point? > > Complexity knows no bounds. > > OT1H I agree that the completion infrastructure would benefit from some > cleanup and is too complex in some areas. OTOH this specific request > doesn't affect the "completion machinery", but only the > `minibuffer-completion-help` functionality which is a fairly simple part > of the code. > >> what's going on is to step with a debugger through the code -- and it >> doesn't help that some of the code is in Lisp and some in C, so Lisp >> calls into C, which calls back into Lisp, etc., thus one needs to >> interrupt the stepping, fire up a different debugger, then go back. > > I luckily haven't had to step through the C code of the completion in > a long while. But the code layout could be improved to better reflect > the architecture of the system (the separation between the "backend" > (completion tables), the "middle end" (completion styles), the standard > minibuffer UI, the in-buffer UI, the completion-list-mode). Since pretty much everything completion related is in minibuffer.el, I wonder if it would be useful to introduce a file separate from minibuffer.el for things which *aren't* related to completion? There are a few of those things in minibuffer.el, and it might help to maintain a stricter separation. And as I mentioned elsewhere, maybe we could move completion-list-mode into minibuffer.el? Then we could be very clear in the commentary of minibuffer.el that despite its name, it is the file where all the completion machinery lives, in or out of the minibuffer. (It would be really nice to be able to just eval minibuffer.el to pick up changes to completion, instead of also having to eval simple.el...) >> Stefan, WDYT? Should we close completion to further development and >> accept only bugfixes? > > =F0=9F=99=82 > > > Stefan