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: Mon, 28 Oct 2024 22:53:59 -0400 Message-ID: References: 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="13874"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 74019@debbugs.gnu.org, Juri Linkov To: Spencer Baugh Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Oct 29 03:55:31 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 1t5cOH-0003Rs-Oy for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 29 Oct 2024 03:55:30 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1t5cNs-0007zf-Fo; Mon, 28 Oct 2024 22:55:04 -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 1t5cNr-0007xp-3a for bug-gnu-emacs@gnu.org; Mon, 28 Oct 2024 22:55:03 -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 1t5cNq-0005ob-R9 for bug-gnu-emacs@gnu.org; Mon, 28 Oct 2024 22:55:02 -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=+5fIiNkfO4kLwnMLxsVVyAGO40rlKXcFeOFb7KJVf8k=; b=o/bDDHjSPSwXALp3wAF16D7vyp0uYZv1HQAcHCZzDX3EnECLC6/h5vXRDjCruR3hpAy2iaCUqw/POdgcqZ+cDQjx4L7eloCn1kqk+qMHDfctJ2OD0QNe7q8nzSj2LAQT9cCp2nKaugzUX+5fiodTX/asvwQiPg+XbaatGNSRgumC0YEkYI5s7BLvvZga4FTL/olCCqPZGY6Vx3+JnztQjPsjN4GjHCUHl00cPhM+feBCXm4r5ToDUh6ZZcQlKRtNM4R5gYIt25h1HuAVTQZL0+oaqCoqFNiw0fReM/RQbXL3zxl1H7bBdYILFh04Ot/DiQHqadbP+CTGlGOD6ZEybg==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1t5cNq-0003i4-Fh for bug-gnu-emacs@gnu.org; Mon, 28 Oct 2024 22:55: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: Tue, 29 Oct 2024 02:55: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.173017045014184 (code B ref 74019); Tue, 29 Oct 2024 02:55:02 +0000 Original-Received: (at 74019) by debbugs.gnu.org; 29 Oct 2024 02:54:10 +0000 Original-Received: from localhost ([127.0.0.1]:55388 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t5cN0-0003gi-0a for submit@debbugs.gnu.org; Mon, 28 Oct 2024 22:54:10 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:43252) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t5cMx-0003gP-Iz for 74019@debbugs.gnu.org; Mon, 28 Oct 2024 22:54:08 -0400 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 078014442C5; Mon, 28 Oct 2024 22:54:02 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1730170440; bh=ihkX8QW92epLZW1Cqcx2v5a5SDRFEDb4k3k8zD+WVa8=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=n0KXFpojOQQExwr4GcfI1PioNPtNI7aeJZP6qEIosc1FFqZJmTT0eSpNEok6UAjfV AShv6AhOHbFXcVEfAnqcZWWfaPjIWQdmY9Ix2ncigZ4dJblQO/4+p4YZvRSb0D09+x f0ygH79iTIG3YKz94GatjRR8XSWnCKLNGUurArjHKBu4vUPM9XMMAWuaf37WXZvjPi gaQOIk4ExnSUUUOSp9hKegJHqBa3WJOgzT+dVs7SBtV7Yu+mSRAKKk7ABDWpTmVyTx X5t58TJJUiEklfPENjuz13a4BocpiRD15FTZ3u1VhNF1q/g+6fRl6JWViFdGIm9itn 8eUYPAkz012ww== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 9F1104443B9; Mon, 28 Oct 2024 22:54:00 -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 6F7FB12013C; Mon, 28 Oct 2024 22:54:00 -0400 (EDT) In-Reply-To: (Spencer Baugh's message of "Mon, 28 Oct 2024 12:01:03 -0400") 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:294465 Archived-At: >> Indeed, it might not be related. E.g in my setup, `*Completions*` is >> placed in a dedicated window&frame that is simply iconified/deiconified >> as needed, so your heuristic would fail. > (Interesting, is the code for that published somewhere? No, it's just in my init file. > What's the motivation for that instead of a window?) My minibuffer is in its own frame so I need another frame to display the completions. > It would be nice to store info about the completion session, but we > don't really have any concrete concept of "a completion session" right > now, right? That's right. =F0=9F=99=81 > Also, I think we sometimes want to avoid reusing *Completions* even > within a completion session: if we're using completion in a directory > tree containing a file /aaa/aaa, if we select "aaa" while completing on > "/a", then "aaa" shouldn't still be selected if we complete on "/aaa/a". I believe we can catch most of those problems by paying attention to changes in `completion-base-position`. [ Tho I think those cases are less problematic, because presumably the "old" selection happened recently enough that the users shouldn't be completely surprised if it's still selected (even though they may consider it as a misfeature). ] > Do you think it would be sufficient to set a "done" buffer-local in > minibuffer-hide-completions? That seems to be called in all the right > places. Yes, I believe that should do it. > Or maybe instead of a buffer-local, we could have > minibuffer-hide-completions do (goto-char (point-min)) so no > completion is selected anymore. Then it becomes harmless to reuse > that *Completions* buffer. Either way works for me. Stefan