From debbugs-submit-bounces@debbugs.gnu.org Fri Oct 25 17:33:19 2024 Received: (at submit) by debbugs.gnu.org; 25 Oct 2024 21:33:19 +0000 Received: from localhost ([127.0.0.1]:39662 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t4Rvq-00023J-Eb for submit@debbugs.gnu.org; Fri, 25 Oct 2024 17:33:19 -0400 Received: from lists.gnu.org ([209.51.188.17]:49872) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t4Rvo-000239-72 for submit@debbugs.gnu.org; Fri, 25 Oct 2024 17:33:17 -0400 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 1t4RvG-0007Zq-KJ for bug-gnu-emacs@gnu.org; Fri, 25 Oct 2024 17:32:43 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1t4RvE-00042e-Kh for bug-gnu-emacs@gnu.org; Fri, 25 Oct 2024 17:32:42 -0400 From: Spencer Baugh To: bug-gnu-emacs@gnu.org Subject: [PATCH] Optionally preserve selected candidate across *Completions* update Date: Fri, 25 Oct 2024 17:32:38 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=waixah; t=1729891958; bh=1mli0snQQenBepKB2YnHq4maJjMec9FajddGv+5NbPo=; h=From:To:Cc:Subject:Date; b=RGDb98ItjzhKOG31w6g6FzQGQJ3MMjeQBq9+Er0vjCtBCJnwRZXmypQjWrbqNFQXM Wu4Lynt8LT6LMak0o0DGktAKcNM85YiUkFtuVavsTRipW/M8J61lVqHtwcuNLQaYvB XJobvKjUC2flGFz7UMh36A6dg4cpa4vcJIuhMCPIEq2SO2R/2FW9pZqDWWuym8G6G+ vEsE22DAWZRAXc/YwZDZgr15bR2p80Y4VInOS/HCZiLeTl7Qxp7f7Z7f5tN3AGcPdj JpCtHXcl+sdKlnrC8KEDgbO6ww/tRkvgQwyExHTPOPxZmwt2LVErkmStVsc4Jn1T5l o9jCd32UAJwCg== Received-SPF: pass client-ip=64.215.233.18; envelope-from=sbaugh@janestreet.com; helo=mxout5.mail.janestreet.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.4 (-) X-Debbugs-Envelope-To: submit Cc: Juri Linkov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.4 (--) --=-=-= Content-Type: text/plain Tags: patch Add completion-preserve-selection, a defcustom which allows keeping the same selected candidate after *Completions* is updated by minibuffer-completion-help. This works correctly with choose-completion-deselect-if-after: If point is after a completion (such that choose-completion-deselect-if-after=t means it won't be treated as selected), point will still be after that completion after updating the list. 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. Since the default UI doesn't (yet) have support for auto-updating the list of completions, preserving the selected candidate is less significant. But it might be an interesting feature on its own, and it's very non-invasive, so maybe we can turn it on by default. In GNU Emacs 29.2.50 (build 5, x86_64-pc-linux-gnu, X toolkit, cairo version 1.15.12, Xaw scroll bars) of 2024-10-15 built on igm-qws-u22796a Repository revision: 16a2e41014c6ea0f3cf268be8d37fe09aeac231e Repository branch: emacs-29 Windowing system distributor 'The X.Org Foundation', version 11.0.12011000 System Description: Rocky Linux 8.10 (Green Obsidian) Configured using: 'configure --with-x-toolkit=lucid --without-gpm --without-gconf --without-selinux --without-imagemagick --with-modules --with-gif=no --with-tree-sitter --with-native-compilation=aot PKG_CONFIG_PATH=/usr/local/home/garnish/libtree-sitter/0.22.6-1/lib/pkgconfig/' --=-=-= Content-Type: text/patch Content-Disposition: attachment; filename=0001-Optionally-preserve-selected-candidate-across-Comple.patch >From 7708bdbc0641c6468aba70662791d9dda043ff88 Mon Sep 17 00:00:00 2001 From: Spencer Baugh Date: Fri, 25 Oct 2024 16:56:30 -0400 Subject: [PATCH] Optionally preserve selected candidate across *Completions* update * lisp/minibuffer.el (completion-preserve-selection): (minibuffer-completion-help): (minibuffer-next-completion): * lisp/simple.el (choose-completion): (completion-setup-function): --- lisp/minibuffer.el | 29 +++++++++++++++++++++++++---- lisp/simple.el | 39 ++++++++++++++++++++++++--------------- 2 files changed, 49 insertions(+), 19 deletions(-) diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el index 44d07557f48..a18f4330514 100644 --- a/lisp/minibuffer.el +++ b/lisp/minibuffer.el @@ -2538,6 +2538,16 @@ completions--fit-window-to-buffer (resize-temp-buffer-window win)) (fit-window-to-buffer win completions-max-height))) +(defcustom completion-preserve-selection nil + "If non-nil, `minibuffer-completion-help' preserves the selected completion 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*." + :type '(choice (const :tag "Updating *Completions* deselects any completion candidate" t) + (const :tag "Candidates in *Completions* stay selected when the list is updated" nil)) + :version "31.1") + (defcustom completion-auto-deselect t "If non-nil, deselect current completion candidate when you type in minibuffer. @@ -2624,6 +2634,12 @@ minibuffer-completion-help (sort-fun (completion-metadata-get all-md 'display-sort-function)) (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 @@ -2647,7 +2663,7 @@ minibuffer-completion-help ,(when temp-buffer-resize-mode '(preserve-size . (nil . t))) (body-function - . ,#'(lambda (_window) + . ,#'(lambda (window) (with-current-buffer mainbuf (when completion-auto-deselect (add-hook 'after-change-functions #'completions--after-change nil t)) @@ -2737,7 +2753,14 @@ minibuffer-completion-help (if (eq (car bounds) (length result)) 'exact 'finished)))))) - (display-completion-list completions nil group-fun))))) + (display-completion-list completions nil group-fun) + (when (and completion-preserve-selection current-candidate-and-offset) + (with-current-buffer standard-output + (when-let* ((match (text-property-search-forward + 'completion--string (car current-candidate-and-offset) t))) + (goto-char (prop-match-beginning match)) + (forward-char (cdr current-candidate-and-offset)) + (set-window-point window (point))))))))) nil))) nil)) @@ -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))) diff --git a/lisp/simple.el b/lisp/simple.el index 2ffd6e86e56..3a142ef14b3 100644 --- a/lisp/simple.el +++ b/lisp/simple.el @@ -10246,6 +10246,23 @@ choose-completion-deselect-if-after This makes `completions--deselect' effective.") +(defun completions--start-of-candidate-at (position) + "Return the start position of the completion candidate at POSITION." + (save-excursion + (goto-char position) + (let (beg) + (cond + ((and (not (eobp)) + (get-text-property (point) 'completion--string)) + (setq beg (1+ (point)))) + ((and (not (bobp)) + (get-text-property (1- (point)) 'completion--string)) + (setq beg (point)))) + (when beg + (or (previous-single-property-change + beg 'completion--string) + beg))))) + (defun choose-completion (&optional event no-exit no-quit) "Choose the completion at point. If EVENT, use EVENT's position to determine the starting position. @@ -10269,21 +10286,11 @@ choose-completion (or (get-text-property (posn-point (event-start event)) 'completion--string) (error "No completion here")) - (save-excursion - (goto-char (posn-point (event-start event))) - (let (beg) - (cond - ((and (not (eobp)) - (get-text-property (point) 'completion--string)) - (setq beg (1+ (point)))) - ((and (not (bobp)) - (get-text-property (1- (point)) 'completion--string)) - (setq beg (point))) - (t (error "No completion here"))) - (setq beg (or (previous-single-property-change - beg 'completion--string) - beg)) - (get-text-property beg 'completion--string)))))) + (if-let* ((candidate-start + (completions--start-of-candidate-at + (posn-point (event-start event))))) + (get-text-property candidate-start 'completion--string) + (error "No completion here"))))) (unless (buffer-live-p buffer) (error "Destination buffer is dead")) @@ -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) -- 2.39.3 --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 26 02:46:03 2024 Received: (at 74019) by debbugs.gnu.org; 26 Oct 2024 06:46:03 +0000 Received: from localhost ([127.0.0.1]:40384 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t4aYl-0003Pw-6B for submit@debbugs.gnu.org; Sat, 26 Oct 2024 02:46:03 -0400 Received: from eggs.gnu.org ([209.51.188.92]:52398) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t4aYi-0003PP-FQ for 74019@debbugs.gnu.org; Sat, 26 Oct 2024 02:46:02 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1t4aY2-0007GK-Pj; Sat, 26 Oct 2024 02:45:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=FBcJwYucmhFiJMfr6IUH9zNc5QnumblE2HfqQSzM+Ho=; b=ITJa6DXSN53s ontfIfSGEzbxfUNxtBpKOSa5GNkC+tDNp8AImwKPDsA7VH9JOGcvAYtXdo0Bn7W9Gw8BjSj7c+cZ7 PO+0uPbPJ36M1YMtIDqp3eZL4lO/Ddp1WnBFz4ngbAvUTQEoI5B29AL+/HrhbEZ+EAojURhJ1hfz9 G5ULE3+/1VFxo8fxzVOKTxaNMqj6jb3JyAX8mcGtlw1euY+wbuugj03kscnrcDpit2An9eO2HwYbK SK6lhIBpKDtAY3GEALzLtcBHm21W6H0FEyV8v5xwCbn7cperz4dEWjV+CA5A5K9euYgDJlsLiKnDJ V9gesRMG4/HOpbCM8FJAFQ==; Date: Sat, 26 Oct 2024 09:45:14 +0300 Message-Id: <86a5erbbwl.fsf@gnu.org> From: Eli Zaretskii To: Spencer Baugh , Stefan Monnier , Stefan Kangas , Andrea Corallo In-Reply-To: (bug-gnu-emacs@gnu.org) Subject: Re: bug#74019: [PATCH] Optionally preserve selected candidate across *Completions* update References: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74019 Cc: 74019@debbugs.gnu.org, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: Juri Linkov > Date: Fri, 25 Oct 2024 17:32:38 -0400 > From: Spencer Baugh via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" > > Add completion-preserve-selection, a defcustom which allows keeping the > same selected candidate after *Completions* is updated by > minibuffer-completion-help. Shouldn't we stop complicating the completion machinery at some point? It is already basically impenetrable, and if someone still can reason about what it does in any specific case, my hat's off to them; I have long ago reached the point where the _only_ way of understanding 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. Stefan, WDYT? Should we close completion to further development and accept only bugfixes? What do Stefan Kangas and Andrea think? > +(defcustom completion-preserve-selection nil > + "If non-nil, `minibuffer-completion-help' preserves the selected completion candidate. This doc-string line is too long. I also don't like the name: "selection" could be confused to mean the X selection. I'd use "selected-candidates" instead. > +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*." This is completely unclear: what does minibuffer-completion-help have to do with updating *Completions*? > + (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)))))) Why is this done unconditionally? with-selected-window is not a cheap function. > @@ -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)) Why is this being moved to a different place? From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 26 10:50:05 2024 Received: (at 74019) by debbugs.gnu.org; 26 Oct 2024 14:50:05 +0000 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 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 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== 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) 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) From: Stefan Monnier To: Spencer Baugh Subject: Re: bug#74019: [PATCH] Optionally preserve selected candidate across *Completions* update In-Reply-To: (Spencer Baugh's message of "Fri, 25 Oct 2024 17:32:38 -0400") Message-ID: References: Date: Sat, 26 Oct 2024 10:49:19 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.144 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74019 Cc: 74019@debbugs.gnu.org, Juri Linkov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > 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 From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 26 11:00:02 2024 Received: (at 74019) by debbugs.gnu.org; 26 Oct 2024 15:00:03 +0000 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 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 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== 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) 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) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#74019: [PATCH] Optionally preserve selected candidate across *Completions* update In-Reply-To: <86a5erbbwl.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 26 Oct 2024 09:45:14 +0300") Message-ID: References: <86a5erbbwl.fsf@gnu.org> Date: Sat, 26 Oct 2024 10:59:18 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.052 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74019 Cc: Spencer Baugh , Andrea Corallo , Stefan Kangas , 74019@debbugs.gnu.org, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > 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 From debbugs-submit-bounces@debbugs.gnu.org Sun Oct 27 03:59:13 2024 Received: (at 74019) by debbugs.gnu.org; 27 Oct 2024 07:59:13 +0000 Received: from localhost ([127.0.0.1]:43678 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t4yB7-0007Vb-5B for submit@debbugs.gnu.org; Sun, 27 Oct 2024 03:59:13 -0400 Received: from relay1-d.mail.gandi.net ([217.70.183.193]:52597) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t4yB5-0007VL-Du for 74019@debbugs.gnu.org; Sun, 27 Oct 2024 03:59:11 -0400 Received: by mail.gandi.net (Postfix) with ESMTPSA id C49BA240003; Sun, 27 Oct 2024 07:58:28 +0000 (UTC) From: Juri Linkov To: Eli Zaretskii Subject: Re: bug#74019: [PATCH] Optionally preserve selected candidate across *Completions* update In-Reply-To: <86a5erbbwl.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 26 Oct 2024 09:45:14 +0300") Organization: LINKOV.NET References: <86a5erbbwl.fsf@gnu.org> Date: Sun, 27 Oct 2024 09:55:04 +0200 Message-ID: <86r082athz.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/31.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-GND-Sasl: juri@linkov.net X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 74019 Cc: Spencer Baugh , Andrea Corallo , Stefan Monnier , 74019@debbugs.gnu.org, Stefan Kangas X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) >> Add completion-preserve-selection, a defcustom which allows keeping the >> same selected candidate after *Completions* is updated by >> minibuffer-completion-help. > > Shouldn't we stop complicating the completion machinery at some point? > It is already basically impenetrable, and if someone still can reason > about what it does in any specific case, my hat's off to them; I have > long ago reached the point where the _only_ way of understanding > 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. The last sorely missing feature related to the completions window is auto-updating the list of completions as you type. There are several proposed implementations, and we have to merge them sooner or later. IIUC, this patch makes preparations to achieve this goal sooner. From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 28 09:52:24 2024 Received: (at 74019) by debbugs.gnu.org; 28 Oct 2024 13:52:24 +0000 Received: from localhost ([127.0.0.1]:52968 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t5QAR-0001MS-JG for submit@debbugs.gnu.org; Mon, 28 Oct 2024 09:52:24 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:38153) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t5QAQ-0001MD-Bq for 74019@debbugs.gnu.org; Mon, 28 Oct 2024 09:52:22 -0400 From: Spencer Baugh To: Stefan Monnier Subject: Re: bug#74019: [PATCH] Optionally preserve selected candidate across *Completions* update In-Reply-To: (Stefan Monnier's message of "Sat, 26 Oct 2024 10:49:19 -0400") References: Date: Mon, 28 Oct 2024 09:51:40 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=waixah; t=1730123500; bh=oB1fh6eQ+JvzeJyM9zWrYtXns80pEJboXFD1RtYnrGs=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=MY1BHRieJPGGarYnF0eTKFKXEuMrDT/e3/hEfW49BJOsQFbeQQCN0lwjK4o08W8d5 HRCzChIRLrwUbxxLipfEkGrRu8vzYQUXcjMQW/UMcapSdU3ioPVsDPtQn3H/VtzVhy PwMfQ4OWi3VCqkPzciWN4VLKHdF7+NaOvqbim2nXGsKiY6/SXfJQ13cq15RMqrad+i 9GhLnblTmfB+fMYtu8bJ++q5cEdkokI9Mc8Bsm1SlOWzCwsQMb9Be88C9LnKSfO0KK KGH2eTcNtff5fmz/nUzfHrccePfWI2ekWzKwY+nGJjRsr2gg0FFftcnK2oYX8M8g4E gjFSTPFkjpF5Q== X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74019 Cc: 74019@debbugs.gnu.org, Juri Linkov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Stefan Monnier writes: >> 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 paragra= ph? Eh, well, it's just that a completion can be "selected" in two different ways: A. if point is on the completion, then choose-completion will always choose it B. if point is right after the completion, then choose-completion will choose it if choose-completion-deselect-if-after is nil The location of point in the completion is preserved, so these two different behaviors are preserved. It's just to contrast with another possible approach, where I only preserve what completion was selected, by moving point to its start after updating. That wouldn't preserve the same behavior in case B. Will improve commit message in next version. >> 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? It's a fair point. We could always add the config var later if we end up wanting it - it's very easy. So I think it would make sense to remove the config var, and always have this preservation behavior, if people are OK with that. That would be less complex. >> * 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 Yes :) Just wanted to get initial feedback. > [ BTW, I really regret not moving the `completion-list-mode` out of > `simple.el`. ] Maybe we could still do that? It would definitely make completion UI changes a lot easier... >> + "If non-nil, `minibuffer-completion-help' preserves the selected comp= letion 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. Will update in next version. >> @@ -2624,6 +2634,12 @@ minibuffer-completion-help >> (sort-fun (completion-metadata-get all-md 'display-sort-fu= nction)) >> (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. That's why I'm doing get-buffer-window here - I figure that if *Completions* is currently displayed in a window, it's reasonable to preserve the selected candidate. (The selected candidate in that window, I guess - so maybe I should use window-point here?) It still might not be related to the current completion session, since the user might have just manually switched buffers to *Completions*, but I wasn't sure there was a good way to determine that... any suggestions? >> @@ -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? Prevuously cursor-face-highlight-nonselected-window was only set by next-completion, but minibuffer-completion-help creates a new *Completions* buffer which doesn't have it set, so the selected completion isn't highlighted. Moving that to completion-setup-function causes it to still be highlighted. This is kind of an unrelated improvement, since this is probably nicer anyway - if the user moves point around manually in *Completions*, IMO that should have the same behavior as minibuffer-next-completion, but currently it doesn't highlight the same way if they leave *Completions* because cursor-face-highlight-nonselected-window doesn't get set. From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 28 09:58:22 2024 Received: (at 74019) by debbugs.gnu.org; 28 Oct 2024 13:58:22 +0000 Received: from localhost ([127.0.0.1]:54241 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t5QGD-0001tk-U9 for submit@debbugs.gnu.org; Mon, 28 Oct 2024 09:58:22 -0400 Received: from mxout6.mail.janestreet.com ([64.215.233.21]:43375) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t5QGB-0001tX-MA for 74019@debbugs.gnu.org; Mon, 28 Oct 2024 09:58:20 -0400 From: Spencer Baugh To: Eli Zaretskii Subject: Re: bug#74019: [PATCH] Optionally preserve selected candidate across *Completions* update In-Reply-To: <86a5erbbwl.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 26 Oct 2024 09:45:14 +0300") References: <86a5erbbwl.fsf@gnu.org> Date: Mon, 28 Oct 2024 09:57:38 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=waixah; t=1730123858; bh=NrFGLeKKICd/BVwk9omXMq5lKJ9VMbAP63hRs7AVWYE=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=obtvypK+zu1G8GOFwmNQfLE2fBtvY4veX4ax/tqz139QaToARROgKA4DHB/qi51zp EWSDPNsCp2f2vZhB48/ibF+80Kc0/GtUn4aDFllvTtmpAENA1UIdv95s5IkVfxlXqS 9lfvSclwLmzOkood4qVE877vyGb+/7S4u2/NOSueiVByWL2de6L2m2SisADNqeGrE7 K4s6WbRC+yLpWiyGO/5O1+tasJcbd0N0qgOZG49KQGM3EWk+5HIm8cidsczUDrh0nE SYBIJlzWPEg09QaZHJ7LxYFqYe/zgVPXYFQDUvuM9xRcH9ra0Ra2vGHGomurTkuG1H XgpFJ2DPyY8XQ== X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74019 Cc: juri@linkov.net, Andrea Corallo , Stefan Monnier , 74019@debbugs.gnu.org, Stefan Kangas X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> Cc: Juri Linkov >> Date: Fri, 25 Oct 2024 17:32:38 -0400 >> From: Spencer Baugh via "Bug reports for GNU Emacs, >> the Swiss army knife of text editors" >> >> Add completion-preserve-selection, a defcustom which allows keeping the >> same selected candidate after *Completions* is updated by >> minibuffer-completion-help. > > Shouldn't we stop complicating the completion machinery at some point? > It is already basically impenetrable, and if someone still can reason > about what it does in any specific case, my hat's off to them; I have > long ago reached the point where the _only_ way of understanding > 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. > > Stefan, WDYT? Should we close completion to further development and > accept only bugfixes? > > What do Stefan Kangas and Andrea think? FWIW, this patch is a very surface-level improvement to the default completion UI, it doesn't deal with the deeper complicated parts of the completion machinery. >> +(defcustom completion-preserve-selection nil >> + "If non-nil, `minibuffer-completion-help' preserves the selected completion candidate. > > This doc-string line is too long. > > I also don't like the name: "selection" could be confused to mean the > X selection. I'd use "selected-candidates" instead. Will change. >> +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*." > > This is completely unclear: what does minibuffer-completion-help have > to do with updating *Completions*? That's fair. minibuffer-completion-help is the function which updates *Completions*, but a user doesn't necessarily know that. Will clarify in next version. >> + (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)))))) > > Why is this done unconditionally? with-selected-window is not a cheap > function. Will avoid the with-selected-window in the next version - a with-current-buffer is sufficient. >> @@ -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)) > > Why is this being moved to a different place? See my reply to Stefan. From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 28 10:09:12 2024 Received: (at 74019) by debbugs.gnu.org; 28 Oct 2024 14:09:12 +0000 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 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 From: Spencer Baugh To: Stefan Monnier Subject: Re: bug#74019: [PATCH] Optionally preserve selected candidate across *Completions* update In-Reply-To: (Stefan Monnier's message of "Sat, 26 Oct 2024 10:59:18 -0400") References: <86a5erbbwl.fsf@gnu.org> Date: Mon, 28 Oct 2024 10:08:27 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74019 Cc: Eli Zaretskii , Andrea Corallo , Stefan Kangas , 74019@debbugs.gnu.org, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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 From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 28 10:22:37 2024 Received: (at 74019) by debbugs.gnu.org; 28 Oct 2024 14:22:37 +0000 Received: from localhost ([127.0.0.1]:54271 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t5Qdh-0002zM-B7 for submit@debbugs.gnu.org; Mon, 28 Oct 2024 10:22:37 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:44704) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t5Qdf-0002z5-6V for 74019@debbugs.gnu.org; Mon, 28 Oct 2024 10:22:36 -0400 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 95DAB4411E2; Mon, 28 Oct 2024 10:21:52 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1730125311; bh=lOK9TF0k5UK0nOZ777rZyyMmVj/+K3lJPJWl50U77Dg=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=VbfpTtTuUQqWwBpi5PS0Xw8vimWjVGB5oy7M7VRPi4PgF0e5N57cYJkwhpyLnCya2 YMuKMOo+A0hT5mFho+04CJbav04dRpPYT8fUIFiQAoIZIJKDIjXwcc+rGMyUaMVDqY 0DQosbD1yEbg9VBzm47JYi4RelTKJZ2nZLrUSZTg8uHVN1I1N/qFnEd7MGypgUePBf 2W+Ja+g36PDRJ463dUL365F8ErDg8mLyKkRl3ee0Z9C20KExjGro5wbI/vJr7UraKT xvy6lEaz3RRKw+8a3+yq3KxZzmC2ZOlRQSQwjoYr9AoPQdcQNa06R6fMd8HvP6uEHF tajuwhZgta5Vw== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 78CA1440B1D; Mon, 28 Oct 2024 10:21:51 -0400 (EDT) Received: from pastel (69-196-161-60.dsl.teksavvy.com [69.196.161.60]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 4C1E412038D; Mon, 28 Oct 2024 10:21:51 -0400 (EDT) From: Stefan Monnier To: Spencer Baugh Subject: Re: bug#74019: [PATCH] Optionally preserve selected candidate across *Completions* update In-Reply-To: (Spencer Baugh's message of "Mon, 28 Oct 2024 09:51:40 -0400") Message-ID: References: Date: Mon, 28 Oct 2024 10:21:49 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.153 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74019 Cc: 74019@debbugs.gnu.org, Juri Linkov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> 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. > > That's why I'm doing get-buffer-window here - I figure that if > *Completions* is currently displayed in a window, it's reasonable to > preserve the selected candidate. > > (The selected candidate in that window, I guess - so maybe I should use > window-point here?) > > It still might not be related to the current completion session, since > the user might have just manually switched buffers to *Completions*, but > I wasn't sure there was a good way to determine that... any suggestions? 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. I think we need to store in the *Completions* buffer some info about the completion session for which it was last used. Or set some buffer-local var that indicates that the corresponding completion session is "done" (we can do that when we hide the *Completions* buffer, when we exit the minibuffer or the `completion-in-region-mode`). > This is kind of an unrelated improvement, since this is probably nicer > anyway - if the user moves point around manually in *Completions*, IMO > that should have the same behavior as minibuffer-next-completion, but > currently it doesn't highlight the same way if they leave *Completions* > because cursor-face-highlight-nonselected-window doesn't get set. I see, thanks. Stefan From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 28 12:01:48 2024 Received: (at 74019) by debbugs.gnu.org; 28 Oct 2024 16:01:48 +0000 Received: from localhost ([127.0.0.1]:54454 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t5SBf-0007Xd-HF for submit@debbugs.gnu.org; Mon, 28 Oct 2024 12:01:47 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:38149) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t5SBd-0007XK-Ik for 74019@debbugs.gnu.org; Mon, 28 Oct 2024 12:01:46 -0400 From: Spencer Baugh To: Stefan Monnier Subject: Re: bug#74019: [PATCH] Optionally preserve selected candidate across *Completions* update In-Reply-To: (Stefan Monnier's message of "Mon, 28 Oct 2024 10:21:49 -0400") References: Date: Mon, 28 Oct 2024 12:01:03 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=waixah; t=1730131263; bh=XOU6RmyBfWp50y+BJLJFJZkxLF1i2FBJi6vQCL/gUcA=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=nNrZ0+xLomKmOBzKk9dy6jUEttRyeqQO4ItswKkuSb5VJmHFZ3f3it4/pBJ/li/09 CQPtvlTQkKnKtSep+RLLS3JjD098sHNXegpZ9Uiio58NrE6E0PB6QKXi5HDkOLsmkq ocol2mh2jWITr+wuLuhVk+kzG61PqjIasLAZKI1Rk2h6NVgVuqaFi5bXjvxPvxAmPd if4eGG84rv2gpdRnGFKo/on7xtZab/rj70dRVZZeire7DwJUbsREXM3ANK2BJXRPC6 k6XEew6T+o/iaLbLdQHV881NJN4fdfneFkikL5jqLroBBzS7fsALr2FDXrcKLM1w0p 8MAfdXRMHtajg== X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74019 Cc: 74019@debbugs.gnu.org, Juri Linkov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Stefan Monnier writes: >>> 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. >> >> That's why I'm doing get-buffer-window here - I figure that if >> *Completions* is currently displayed in a window, it's reasonable to >> preserve the selected candidate. >> >> (The selected candidate in that window, I guess - so maybe I should use >> window-point here?) >> >> It still might not be related to the current completion session, since >> the user might have just manually switched buffers to *Completions*, but >> I wasn't sure there was a good way to determine that... any suggestions? > > 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? What's the motivation for that instead of a window?) > I think we need to store in the *Completions* buffer some info about the > completion session for which it was last used. Or set some buffer-local > var that indicates that the corresponding completion session is "done" > (we can do that when we hide the *Completions* buffer, when we exit the > minibuffer or the `completion-in-region-mode`). 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? So it's not clear to me how we would keep track of when it starts and ends. 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". 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. 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. From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 28 22:54:10 2024 Received: (at 74019) by debbugs.gnu.org; 29 Oct 2024 02:54:10 +0000 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 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 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== 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) 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) From: Stefan Monnier To: Spencer Baugh Subject: Re: bug#74019: [PATCH] Optionally preserve selected candidate across *Completions* update In-Reply-To: (Spencer Baugh's message of "Mon, 28 Oct 2024 12:01:03 -0400") Message-ID: References: Date: Mon, 28 Oct 2024 22:53:59 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.137 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74019 Cc: 74019@debbugs.gnu.org, Juri Linkov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> 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 From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 29 12:25:24 2024 Received: (at 74019) by debbugs.gnu.org; 29 Oct 2024 16:25:24 +0000 Received: from localhost ([127.0.0.1]:57269 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t5p24-0001z8-0e for submit@debbugs.gnu.org; Tue, 29 Oct 2024 12:25:24 -0400 Received: from mxout1.mail.janestreet.com ([38.105.200.78]:54085) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t5p21-0001yq-Ng for 74019@debbugs.gnu.org; Tue, 29 Oct 2024 12:25:22 -0400 From: Spencer Baugh To: Stefan Monnier Subject: Re: bug#74019: [PATCH] Optionally preserve selected candidate across *Completions* update In-Reply-To: (Stefan Monnier's message of "Mon, 28 Oct 2024 22:53:59 -0400") References: Date: Tue, 29 Oct 2024 12:25:15 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=waixah; t=1730219115; bh=UdjG3HU+5yLJNBIIdC3p8jSSD2SvDhiWAS6FoMartfI=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=tx7EtmlisUb0opJW2YlRkqO2zqUOZH7pXymZfGYsrS5lFRKHRUtATz48vYz8v+6uY 6js4RPkGnOqH+SFn7/c4xy98NGjrMx63KAhxPnZjkFOw5A+Sa38A3p/cmuvUD07qY6 bBry9TwlWpctjs9BUJCC93wPChFMDDSCndKP8N564fhD0N2Z7TAscnPIi/amePXg+J MZvKQl5+0NF/zOP87bakGJLS9fUBJ08UeYCP/ePhRGZzjox1NA/g2usCu/KhtMlDOk gWLsd9BrXi4xxovZleC6G3eM1Kh5ZrSzFcAhfq+/mWRl66IVNsfgHVpN4LmjbRTNqj S6naN4mIY227Q== X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74019 Cc: 74019@debbugs.gnu.org, Juri Linkov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain Stefan Monnier writes: >> 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. OK, updated patch with this and other feedback: --=-=-= Content-Type: text/x-patch Content-Disposition: inline; filename=0001-Preserve-selected-candidate-across-Completions-updat.patch >From c9b1336692c095e4f8423797e58aac9fe55325fb Mon Sep 17 00:00:00 2001 From: Spencer Baugh Date: Tue, 29 Oct 2024 12:16:31 -0400 Subject: [PATCH] Preserve selected candidate across *Completions* update When *Completions* is updated and point was on some completion candidate, move point to the same candidate after the update. Also, a selected completion in *Completions* is now always highlighted, even if it was selected by the user or other code moving point rather than by minibuffer-next-completion, because cursor-face-highlight-nonselected-window is now set in completion-setup-function. 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. This matters a lot when completions are auto-updated, but is still useful without auto-updating. Including this behavior is a step towards supporting auto-updating in the default completion UI. * lisp/minibuffer.el (minibuffer-completion-help): Preserve the selected completion candidate across updates. (bug#74019) (minibuffer-hide-completions): Move point to BOB. (minibuffer-next-completion): Don't set cursor-face-highlight-nonselected-window. * lisp/simple.el (completions--start-of-candidate-at) (choose-completion): Extract the current-completion-finding code into a separate function. (completion-setup-function): Set cursor-face-highlight-nonselected-window. * etc/NEWS: Announce new behavior. --- etc/NEWS | 8 ++++++++ lisp/minibuffer.el | 29 +++++++++++++++++++++++------ lisp/simple.el | 39 ++++++++++++++++++++++++--------------- 3 files changed, 55 insertions(+), 21 deletions(-) diff --git a/etc/NEWS b/etc/NEWS index 18b6678dce9..ad85bbf116e 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -86,6 +86,14 @@ different values for completion-affecting variables like applies for the styles configuration in 'completion-category-overrides' and 'completion-category-defaults'. +--- +*** Selected completion candidate is preserved across *Completions* updates. +When point is on a completion candidate in the *Completions* buffer +(because of 'minibuffer-next-completion' or for any other reason), point +will still be on that candidate after *Completions* is updated with a +new list of completions. The candidate is automatically deselected when +the *Completions* buffer is hidden. + ** Windows +++ diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el index 44d07557f48..9b498615926 100644 --- a/lisp/minibuffer.el +++ b/lisp/minibuffer.el @@ -2624,6 +2624,12 @@ minibuffer-completion-help (sort-fun (completion-metadata-get all-md 'display-sort-function)) (group-fun (completion-metadata-get all-md 'group-function)) (mainbuf (current-buffer)) + (current-candidate-and-offset + (when-let* ((buffer (get-buffer "*Completions*")) + (window (get-buffer-window buffer 0))) + (with-current-buffer buffer + (when-let* ((beg (completions--start-of-candidate-at (window-point window)))) + (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 @@ -2647,7 +2653,7 @@ minibuffer-completion-help ,(when temp-buffer-resize-mode '(preserve-size . (nil . t))) (body-function - . ,#'(lambda (_window) + . ,#'(lambda (window) (with-current-buffer mainbuf (when completion-auto-deselect (add-hook 'after-change-functions #'completions--after-change nil t)) @@ -2737,7 +2743,16 @@ minibuffer-completion-help (if (eq (car bounds) (length result)) 'exact 'finished)))))) - (display-completion-list completions nil group-fun))))) + (display-completion-list completions nil group-fun) + (when current-candidate-and-offset + (with-current-buffer standard-output + (when-let* ((match (text-property-search-forward + 'completion--string (car current-candidate-and-offset) t))) + (goto-char (prop-match-beginning match)) + ;; Preserve the exact offset for the sake of + ;; `choose-completion-deselect-if-after'. + (forward-char (cdr current-candidate-and-offset)) + (set-window-point window (point))))))))) nil))) nil)) @@ -2746,8 +2761,12 @@ minibuffer-hide-completions ;; FIXME: We could/should use minibuffer-scroll-window here, but it ;; can also point to the minibuffer-parent-window, so it's a bit tricky. (interactive) - (let ((win (get-buffer-window "*Completions*" 0))) - (if win (with-selected-window win (bury-buffer))))) + (when-let* ((win (get-buffer-window "*Completions*" 0))) + (with-selected-window win + ;; Move point off any completions, so we don't move point there + ;; again the next time `minibuffer-completion-help' is called. + (goto-char (point-min)) + (bury-buffer)))) (defun exit-minibuffer () "Terminate this minibuffer argument." @@ -4905,8 +4924,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))) diff --git a/lisp/simple.el b/lisp/simple.el index 2ffd6e86e56..3a142ef14b3 100644 --- a/lisp/simple.el +++ b/lisp/simple.el @@ -10246,6 +10246,23 @@ choose-completion-deselect-if-after This makes `completions--deselect' effective.") +(defun completions--start-of-candidate-at (position) + "Return the start position of the completion candidate at POSITION." + (save-excursion + (goto-char position) + (let (beg) + (cond + ((and (not (eobp)) + (get-text-property (point) 'completion--string)) + (setq beg (1+ (point)))) + ((and (not (bobp)) + (get-text-property (1- (point)) 'completion--string)) + (setq beg (point)))) + (when beg + (or (previous-single-property-change + beg 'completion--string) + beg))))) + (defun choose-completion (&optional event no-exit no-quit) "Choose the completion at point. If EVENT, use EVENT's position to determine the starting position. @@ -10269,21 +10286,11 @@ choose-completion (or (get-text-property (posn-point (event-start event)) 'completion--string) (error "No completion here")) - (save-excursion - (goto-char (posn-point (event-start event))) - (let (beg) - (cond - ((and (not (eobp)) - (get-text-property (point) 'completion--string)) - (setq beg (1+ (point)))) - ((and (not (bobp)) - (get-text-property (1- (point)) 'completion--string)) - (setq beg (point))) - (t (error "No completion here"))) - (setq beg (or (previous-single-property-change - beg 'completion--string) - beg)) - (get-text-property beg 'completion--string)))))) + (if-let* ((candidate-start + (completions--start-of-candidate-at + (posn-point (event-start event))))) + (get-text-property candidate-start 'completion--string) + (error "No completion here"))))) (unless (buffer-live-p buffer) (error "Destination buffer is dead")) @@ -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) -- 2.39.3 --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 29 14:27:50 2024 Received: (at 74019) by debbugs.gnu.org; 29 Oct 2024 18:27:50 +0000 Received: from localhost ([127.0.0.1]:57953 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t5qwX-0005i6-QY for submit@debbugs.gnu.org; Tue, 29 Oct 2024 14:27:50 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:2957) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t5qwV-0005hy-1V for 74019@debbugs.gnu.org; Tue, 29 Oct 2024 14:27:47 -0400 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 48522442129; Tue, 29 Oct 2024 14:27:40 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1730226459; bh=aWgVM7nq+qMeOln8jEyf2A0tkvMfSDWGECcXNg4ZlHs=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=V35O/BxItoWMVd8Io8bumjSNwz6A9GP5hzpykapv1cUyJykt9G3l4FS6vRpqIDkar PA9wep+uzCnDCa+TtcxZKqldhdG3vTuJ5Cc5Z8geerdWoqWwg07Vqs1Z51yy40RRas c4mvlpxonCr5gDB2FTcgUrUGbi33ytieXNsBrACKQ7QS7asJrknyG6wSfLKPZNWEYg WtvGox3B32ep3BxBbkLoL8S34l95V93DLr4Ma0ESsAI0DxSqLxmLgZ6biO4LosjL2H uPVOO0zPuoiK/NRrpWwhFY4khienxjvMTOXtjqOSJU2uR5JVh8w1TvXAiK0fdJ8Rge P9bajVliOw0/g== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 723B144210A; Tue, 29 Oct 2024 14:27:39 -0400 (EDT) Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 632EC120497; Tue, 29 Oct 2024 14:27:39 -0400 (EDT) From: Stefan Monnier To: Spencer Baugh Subject: Re: bug#74019: [PATCH] Optionally preserve selected candidate across *Completions* update In-Reply-To: (Spencer Baugh's message of "Tue, 29 Oct 2024 12:25:15 -0400") Message-ID: References: Date: Tue, 29 Oct 2024 14:27:37 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.209 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74019 Cc: 74019@debbugs.gnu.org, Juri Linkov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > OK, updated patch with this and other feedback: Looks OK to me, thank you. Stefan From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 03 01:49:57 2024 Received: (at control) by debbugs.gnu.org; 3 Nov 2024 05:49:57 +0000 Received: from localhost ([127.0.0.1]:58061 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t7TUq-0000Sr-TG for submit@debbugs.gnu.org; Sun, 03 Nov 2024 01:49:57 -0400 Received: from mail-wr1-f42.google.com ([209.85.221.42]:45231) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t7TUo-0000Sk-VW for control@debbugs.gnu.org; Sun, 03 Nov 2024 01:49:55 -0400 Received: by mail-wr1-f42.google.com with SMTP id ffacd0b85a97d-37d462c91a9so1945059f8f.2 for ; Sat, 02 Nov 2024 22:49:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1730612929; x=1731217729; darn=debbugs.gnu.org; h=to:subject:message-id:date:mime-version:from:from:to:cc:subject :date:message-id:reply-to; bh=erhTmNBXU+usVRkX3lQ71+ZBMOSAtuxR828R7+GaIlE=; b=GRuwqPOtti+woa0opCVevwKMf2wNhJT2VGwkbT0/BJBajv+dV14AKu2qMmv3lC0p3D KzAQj5/nYNzTFa+IY2u0/kBaL5dFceDUqRPvJxsonbtBYOQ3UXJgB1X91lajMloWsSMI hLPrcdpS4VF8RxegiF1y1eI+HhXi11PySHrCqsbkOQjvgbHIXpww4w4rugUzRHpsBDnV +pmxTwNut6QRPMmw+sP9W04ZXF1ZQwYB5dEqjM5wYYA2isPFL3fveo+S3HerVmU1N4Q5 rzgVx2IjS0Tfq5M0sPXE/Vovdn+KvsFWFOUKwhtgJfqYpIjPLLexZn2rYojH4R+rPgMl Qy8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730612929; x=1731217729; h=to:subject:message-id:date:mime-version:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=erhTmNBXU+usVRkX3lQ71+ZBMOSAtuxR828R7+GaIlE=; b=dtOvZ4iYIfqFEpQPAylNN8nH0/2v2mQGMvfT7Pqeo19h8dvtGLillxAS4ie244zfFj I12gV9J9yxXpYd21ohPbY87LJe0ZpRIylDrVa4Fr4pVi3cjLrJmli9gsKzwQXcElKq2q t9j/0XkU2BO6w5vXq2NX51Z4pewmP8vgWbhP2UCYsE03AhU44UlP2/BXdnZ4uXy3WmxW 73cRyun8oYmqMwy7RaMHpy2MUJzzU6SLmrqFCEEMYjzbR3O3+O+Ou0xhp4r55SmWZICg DR1y0+6Q0ua7UfLoJrJ+gnoqDHS702bJgBCip4YDTmIa01vJGcovVOqYkxI5BjG6d04N 6U+w== X-Gm-Message-State: AOJu0YzaTudFeuFFItnQAICb0zcxw8OQreu5sd7uKLbbj6EL34bj4TV5 H4MMmx2etmDnQakmSLat7pL109KZK8TBQWPt7yyZLmA8JbG9NOSBIAr1wRpDloiHC36K373pDYH 7LfT5PsBWwwyXZXuGkTlNk4JXDypSNg== X-Google-Smtp-Source: AGHT+IEEsq5Iq2z2ajd5MOJoC3RbMHNUnaR5TbcQAg0jVtDdBOrY3S7UYvR8TnzpKR1yylQ7DgpERiGBA8sT9CT5OWE= X-Received: by 2002:adf:f3c6:0:b0:37d:3735:8fe9 with SMTP id ffacd0b85a97d-381b708ab7cmr11530510f8f.27.1730612929022; Sat, 02 Nov 2024 22:48:49 -0700 (PDT) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Sat, 2 Nov 2024 22:48:48 -0700 From: Stefan Kangas MIME-Version: 1.0 Date: Sat, 2 Nov 2024 22:48:48 -0700 Message-ID: Subject: control message for bug #74019 To: control@debbugs.gnu.org Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) severity 74019 wishlist quit From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 13 16:13:17 2024 Received: (at 74019) by debbugs.gnu.org; 13 Nov 2024 21:13:17 +0000 Received: from localhost ([127.0.0.1]:43905 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBKfs-0003Ym-P3 for submit@debbugs.gnu.org; Wed, 13 Nov 2024 16:13:16 -0500 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:45703) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBKfq-0003YW-90 for 74019@debbugs.gnu.org; Wed, 13 Nov 2024 16:13:14 -0500 From: Spencer Baugh To: Stefan Monnier Subject: Re: bug#74019: [PATCH] Optionally preserve selected candidate across *Completions* update In-Reply-To: (Spencer Baugh's message of "Tue, 29 Oct 2024 12:25:15 -0400") References: Date: Wed, 13 Nov 2024 16:13:08 -0500 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=waixah; t=1731532389; bh=nk3m8lhuUs1oJb0W3WW75tGblN2SIcb4dloCTDeT/Zo=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=QAxVUAyvxlItHZcVu7KNlB0wFUrqbJM5q6hN4Zqlmmvjv1IsQO64lxcMBb7aKG/n0 tMECIw5bTGbbxkQz8x/xsXltpawq7QOif/TiJOyNsa8b2j2QJGXAIfHhTvx192SgSh j/6RxYmabfoat+LPdb80exywos4LaxRygqHjvsxfZBbflMqzi6UsX3f/7BKbLBQoAY jqrP3q2HAI2h1xeMaFvhKXVvw9w0+f33Ax7hQBZD63lyb+4n4dWSqzahLjK1JDDwLj Htzzy1ttVRBtT/IphLL5xSw4mVpo9qnttbE3k6r7H5tRlD5l713VuKTCRg8NhNunfn DVlXLctE1tZYg== X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74019 Cc: Eli Zaretskii , Andrea Corallo , Stefan Kangas , 74019@debbugs.gnu.org, Juri Linkov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Spencer Baugh writes: > OK, updated patch with this and other feedback: Stefan is okay with this patch and there's been no more feedback; could we install this now? From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 14 10:47:18 2024 Received: (at 74019) by debbugs.gnu.org; 14 Nov 2024 15:47:18 +0000 Received: from localhost ([127.0.0.1]:46821 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBc3x-0005SB-Ox for submit@debbugs.gnu.org; Thu, 14 Nov 2024 10:47:17 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:42250) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBc3v-0005Rx-DT for 74019@debbugs.gnu.org; Thu, 14 Nov 2024 10:47:15 -0500 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 0A299809AC; Thu, 14 Nov 2024 10:47:10 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1731599229; bh=HNxuMTblEMMggaN03juUeqQe7y2ZXY73nzWMbMRiUkQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=SlkF8tiT5ZwKdmBqxDd8j3fXvG5q0Q4hOJHXfQ4VIy3Y8/N8Tbpnsd63XImjWJQlY QOfTB3TV2LduX2RVUFe/fbAt59fdAaSxZw8xzYwMTeuS3fG95CQ4zypwAR3XMkRNZp kVNiW0ReEb8ouFcL9CUSiFuigdpz8BQbrG4GmZUJ5WthEdLxgiY0478DTQuPMlZUSV jCiNI7z5rRHKrfG133wMut//RkcgjDYRpAFgmvCpCsP9vzMKSGkFuG2zlrPv63DaH7 K3gHzr+w408dojvLmuNZO7VN7tvQZXcUKdvjYHzhgck/hIOn23fzYJimD8E+oG3NSl egURozBvPY2SA== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 580538092E; Thu, 14 Nov 2024 10:47:09 -0500 (EST) Received: from alfajor (modemcable005.21-80-70.mc.videotron.ca [70.80.21.5]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 3AA921202E2; Thu, 14 Nov 2024 10:47:09 -0500 (EST) From: Stefan Monnier To: Spencer Baugh Subject: Re: bug#74019: [PATCH] Optionally preserve selected candidate across *Completions* update In-Reply-To: (Spencer Baugh's message of "Tue, 29 Oct 2024 12:25:15 -0400") Message-ID: References: Date: Thu, 14 Nov 2024 10:47:08 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.398 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74019 Cc: 74019@debbugs.gnu.org, Juri Linkov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > OK, updated patch with this and other feedback: Thanks, pushed to `master`. Stefan From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 14 12:09:21 2024 Received: (at 74019-done) by debbugs.gnu.org; 14 Nov 2024 17:09:21 +0000 Received: from localhost ([127.0.0.1]:47006 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBdLM-00016d-NN for submit@debbugs.gnu.org; Thu, 14 Nov 2024 12:09:20 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:53188) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBdLI-00016F-1Z for 74019-done@debbugs.gnu.org; Thu, 14 Nov 2024 12:09:20 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 9A71644289F; Thu, 14 Nov 2024 12:09:10 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1731604149; bh=u9oQkeLfnymJIhlnUO14mXpipFNk/LVXuxoMp61U09c=; h=From:To:Subject:In-Reply-To:References:Date:From; b=RaGhKGWAcDiZY5GqiP8IzlCcRu/T9mWP7GGlkQzxlxhQal+B+ygv54k+k+aRUw6LI nzJchTUuaHOpJdvSOCPg/rU7QKb+BOFGD6lo6aQRUSbDTc/iIXt3ggup5fumNPbfHL 5WcbsJuisxUmsZ2v9QwNtHRAJ9I4P7HqlIG0D6PO4mVBkWTsN16Kbkc+5CPOBiDrla Nc6gZPQ6pA0aLz63/min3pzmFqShzLScjOcbdEWRC/k3gpHNgmolYjLDN8XNNmS0Fj ucfhH5fQ9PtVgIPo4zVtoYKOUKJy3EeXbgJTRaNhAG1gUQ05YzOoJI+XBBYCsb8u+6 thsbRSHnygT0A== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id B65C24426CF; Thu, 14 Nov 2024 12:09:09 -0500 (EST) Received: from alfajor (modemcable005.21-80-70.mc.videotron.ca [70.80.21.5]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 9BDC6120399; Thu, 14 Nov 2024 12:09:09 -0500 (EST) From: Stefan Monnier To: 74019-done@debbugs.gnu.org Subject: Re: bug#74019: [PATCH] Optionally preserve selected candidate across *Completions* update In-Reply-To: (Stefan Monnier's message of "Thu, 14 Nov 2024 10:47:08 -0500") Message-ID: References: Date: Thu, 14 Nov 2024 12:09:09 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.071 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74019-done X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Thanks, pushed to `master`. Closing, Stefan From unknown Sun Jun 22 03:58:01 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Fri, 13 Dec 2024 12:24:09 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator