From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier 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: Sat, 26 Oct 2024 10:59:18 -0400 Message-ID: References: <86a5erbbwl.fsf@gnu.org> Reply-To: Stefan Monnier 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="31505"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Spencer Baugh , Andrea Corallo , Stefan Kangas , 74019@debbugs.gnu.org, juri@linkov.net To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Oct 26 17:01:11 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 1t4iHt-0007z2-Vy for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 26 Oct 2024 17:01:10 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1t4iHG-000338-9x; Sat, 26 Oct 2024 11:00:30 -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 1t4iHE-00032Z-QL for bug-gnu-emacs@gnu.org; Sat, 26 Oct 2024 11:00:29 -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 1t4iHE-00014h-HR for bug-gnu-emacs@gnu.org; Sat, 26 Oct 2024 11:00:28 -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=9wbOfUU8vg7WjXpY5CmSA7sfKlPlcb9VqB6iiLa8RTE=; b=JXYTbFYHJy/YeXT+u34OWPoKiNPWjcR53T46T+kRPOP7p1cK7W6h/sMgm8/L+I8OvvuKUwxepFnt4ZH6eU0Im0BlmIwcNOxM1DaPQrvLgOGMbAoT9PkMr+z/72gC5wdzw1QDi0kd7eMK27Wu92mkAbuFRsQysyoxs9Igi0xrPm35T5b/LaZKctHcB/sAdZ8MIDKHIr9/QhWsE9VVj6+6jP8/pnyDIxdC5tzS4VQQUTHfFOOmC3kz/elngjU0BZ992/OZSwu99VsmXnQnOOwOY8uelyxGEPNsNaREll0+FiM2xJJYDSYn70Z8HgNpTwSnuVr2hS06O2aLSGnbF1ns4A==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1t4iHl-00023n-Lj for bug-gnu-emacs@gnu.org; Sat, 26 Oct 2024 11:01:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 26 Oct 2024 15:01:01 +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.17299548037377 (code B ref 74019); Sat, 26 Oct 2024 15:01:01 +0000 Original-Received: (at 74019) by debbugs.gnu.org; 26 Oct 2024 15:00:03 +0000 Original-Received: from localhost ([127.0.0.1]:42268 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t4iGo-0001uj-0M for submit@debbugs.gnu.org; Sat, 26 Oct 2024 11:00:02 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:3049) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t4iGl-0001u7-Kc for 74019@debbugs.gnu.org; Sat, 26 Oct 2024 11:00:00 -0400 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 43FB580904; Sat, 26 Oct 2024 10:59:20 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1729954759; bh=2UA/Yz5jbshb0YGFo+iqaCtHMgg9NkU8qOe/hi32WAM=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=DOzU5LGnj199WXoKywpdxt4XQFA0fKYOGJYvo56kf7MV08VBcZ4SVxaH5oSKcNIcK GiOyX6HishUENIUj5fFE/3khbChEC45IT73CyySVdrjNcpCfLCydWIDEchyuiuA0GA GH4iiPkK6yieX3KXwXOPGUnUs1VaC1KbXQUnFC4MyjUQ4vvc5Pct+NOqHDXg5leRPA GR2DjrUvAFEskEmjdbmBzBVriwYffim6YfWDMf6nXX7lfBhZudVpgsKo2BuS3owdNF R0P+czNKyO5Z1YRdx6Saq1gn0C2EdYmJakwU+bmsubA84bowmZCaFW4zExkEJGAfOq jz37ndjpxhthg== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 6EC80805DE; Sat, 26 Oct 2024 10:59:19 -0400 (EDT) Original-Received: from pastel (69-196-161-60.dsl.teksavvy.com [69.196.161.60]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 32305120682; Sat, 26 Oct 2024 10:59:19 -0400 (EDT) In-Reply-To: <86a5erbbwl.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 26 Oct 2024 09:45:14 +0300") 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:294280 Archived-At: > 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). > Stefan, WDYT? Should we close completion to further development and > accept only bugfixes? =F0=9F=99=82 Stefan