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:49:19 -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="31816"; 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 Sat Oct 26 16:50:53 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 1t4i7w-00087v-0Z for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 26 Oct 2024 16:50:52 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1t4i7c-0002Li-07; Sat, 26 Oct 2024 10:50:32 -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 1t4i7Z-0002L5-Jh for bug-gnu-emacs@gnu.org; Sat, 26 Oct 2024 10:50: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 1t4i7Z-0006H7-Al for bug-gnu-emacs@gnu.org; Sat, 26 Oct 2024 10:50:29 -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=4rpZSeLSGEqQKgehdptgqYWTRqmmdj9s5JnNWizM1Dk=; b=pG1QIz0ljo2DeZtNY/m+tkHdqhYZPcVySkeGGZvuaeuxHKmos7fYrpmE5ZxgVhpZe8CKuFao40F3OLiv7uFQe3WYD1QRaVoaiA39An+RHRYosshVLx1jHTUl0vmCu4O/ESpFc3u+V23k1rM0cIWNEgx3f1uBttnNRUaVYSogm2dwgar0Q1fGn6gI8ajU7hUc87zGlJW9/8XoTi9fD76UIxdKZhB+BpwzmXCS9HZqmWp0UGe1aYh3Yz32WBQY+AZV8+vSv8bedIZxuz/CELyx0sGzQ6nUgbutaRx7g8FE5jZfrnsqu4Gm0/cYGHjJG/1LVcR3iBO1EDRsxx/H72tJfQ==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1t4i86-0001aZ-MH for bug-gnu-emacs@gnu.org; Sat, 26 Oct 2024 10:51: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: Sat, 26 Oct 2024 14:51: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.17299542055681 (code B ref 74019); Sat, 26 Oct 2024 14:51:02 +0000 Original-Received: (at 74019) by debbugs.gnu.org; 26 Oct 2024 14:50:05 +0000 Original-Received: from localhost ([127.0.0.1]:42251 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t4i7A-0001TY-Li for submit@debbugs.gnu.org; Sat, 26 Oct 2024 10:50:05 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:58321) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t4i77-0001Sp-Re for 74019@debbugs.gnu.org; Sat, 26 Oct 2024 10:50:02 -0400 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 4E57F440A2D; Sat, 26 Oct 2024 10:49:22 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1729954160; bh=H/LJfageKEH9OQEyh1whos5prhy3/3Pobmd6I2iM+t0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=BxuQaZnlIi4Xp0Pbmf9G970VcX0qu+rqSZHsJ9lG5kSnSWslrideyiu8+ARvKljIe 3SouLrqEFtu03QsvMlvuypd9ayG34QdXM26OCvutNdiVuvEpxhnAJbsqO4G2bSqPlB h3R+gqE/HPq5HE6SWX5X+IR4rVAqH7510FWaw1G9Byn67WOxIi7ECRofXdLdOGpRRA 8Uu5GjyMqsaHTxcvUAwIGaaHtFExo+MhXaBwBGADEj2c72hVg+BcMDrlkJiwqhKQ2p LccR/wz/X8G1d8z7rASCUoYw7AQOYwGPx8qbCEgosPkzwOWaPzUypNqV4CE+8/S1Q2 0Vr/n/Jm/ydHA== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 2F7D7440774; Sat, 26 Oct 2024 10:49:20 -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 025291203FD; Sat, 26 Oct 2024 10:49:19 -0400 (EDT) In-Reply-To: (Spencer Baugh's message of "Fri, 25 Oct 2024 17:32:38 -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:294278 Archived-At: > Add completion-preserve-selection, a defcustom which allows keeping the > same selected candidate after *Completions* is updated by > minibuffer-completion-help. IIUC, this is a change that affects only `minibuffer-completion-help`, which is part of the standard UI's *Completions*, right, the generic completion infrastructure, right? > This works correctly with choose-completion-deselect-if-after: If point > is after a completion (such that choose-completion-deselect-if-after=3Dt > means it won't be treated as selected), point will still be after that > completion after updating the list. I can't remember what `choose-completion-deselect-if-after` is about, sorry, but the above reads like "the code doesn't have one of the bugs I encountered while implemented the code". Is there more to this paragraph? > This feature is primarily motivated by the fact that some other > completion UIs (e.g. ido, vertico, etc) effectively have this behavior: > whenever they update the list of completions, they preserve whatever > candidate is selected. Are there cases where the current behavior is preferable? IOW, why do we need a config var and why does it default to nil? > * lisp/minibuffer.el (completion-preserve-selection): > (minibuffer-completion-help): > (minibuffer-next-completion): > * lisp/simple.el (choose-completion): > (completion-setup-function): I presume you know that this is incomplete. =F0=9F=99=82 [ BTW, I really regret not moving the `completion-list-mode` out of `simple.el`. ] > + "If non-nil, `minibuffer-completion-help' preserves the selected compl= etion candidate. > + > +If non-nil, and point is on a completion candidate in the displayed > +*Completions* window, `minibuffer-completion-help' will put point on the > +same candidate after updating *Completions*." I think we should be more clear that it *tries* to preserve it. After all, the selected candidate may simply be absent from the new set of candidates. > @@ -2624,6 +2634,12 @@ minibuffer-completion-help > (sort-fun (completion-metadata-get all-md 'display-sort-fun= ction)) > (group-fun (completion-metadata-get all-md 'group-function)) > (mainbuf (current-buffer)) > + (current-candidate-and-offset > + (when-let* ((window (get-buffer-window "*Completions*" 0))) > + (with-selected-window window > + (when-let* ((beg (completions--start-of-candidate-at (= point)))) > + > + (cons (get-text-property beg 'completion--string) (-= (point) beg)))))) > ;; If the *Completions* buffer is shown in a new > ;; window, mark it as softly-dedicated, so bury-buffer in > ;; minibuffer-hide-completions will know whether to Hmm... are we sure here that the `*Completions*`s content is related to the current completion session? I don't think we want to preserve the selection when it came from an unrelated use of completion half an hour earlier. > @@ -4905,8 +4928,6 @@ minibuffer-next-completion > (interactive "p") > (let ((auto-choose minibuffer-completion-auto-choose)) > (with-minibuffer-completions-window > - (when completions-highlight-face > - (setq-local cursor-face-highlight-nonselected-window t)) > (if vertical > (next-line-completion (or n 1)) > (next-completion (or n 1))) [...] > @@ -10451,6 +10458,8 @@ completion-setup-function > (let ((base-position completion-base-position) > (insert-fun completion-list-insert-choice-function)) > (completion-list-mode) > + (when completions-highlight-face > + (setq-local cursor-face-highlight-nonselected-window t)) > (setq-local completion-base-position base-position) > (setq-local completion-list-insert-choice-function insert-fun)) > (setq-local completion-reference-buffer mainbuf) Why? Stefan