X-Loop: help-debbugs@HIDDEN
Subject: bug#68958: [PATCH] Support bookmarking Xref results buffers
Resent-From: Eshel Yaron <me@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: dmitry@HIDDEN, bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 06 Feb 2024 20:19:02 +0000
Resent-Message-ID: <handler.68958.B.170725070210259 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: report 68958
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: 68958 <at> debbugs.gnu.org
Cc: Dmitry Gutov <dmitry@HIDDEN>
X-Debbugs-Original-To: bug-gnu-emacs@HIDDEN
X-Debbugs-Original-Xcc: Dmitry Gutov <dmitry@HIDDEN>
Received: via spool by submit <at> debbugs.gnu.org id=B.170725070210259
(code B ref -1); Tue, 06 Feb 2024 20:19:02 +0000
Received: (at submit) by debbugs.gnu.org; 6 Feb 2024 20:18:22 +0000
Received: from localhost ([127.0.0.1]:55179 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1rXRtd-0002fO-Cb
for submit <at> debbugs.gnu.org; Tue, 06 Feb 2024 15:18:22 -0500
Received: from lists.gnu.org ([2001:470:142::17]:41682)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <me@HIDDEN>) id 1rXRtb-0002f3-5X
for submit <at> debbugs.gnu.org; Tue, 06 Feb 2024 15:18:20 -0500
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 <me@HIDDEN>) id 1rXRtB-0005tH-BM
for bug-gnu-emacs@HIDDEN; Tue, 06 Feb 2024 15:17:53 -0500
Received: from mail.eshelyaron.com ([107.175.124.16] helo=eshelyaron.com)
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <me@HIDDEN>) id 1rXRt7-0004nY-GU
for bug-gnu-emacs@HIDDEN; Tue, 06 Feb 2024 15:17:52 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eshelyaron.com;
s=mail; t=1707250668;
bh=MrrAU2IEG25ixpxx7URyEeirK1Q00aDCvX9Hl6ZKT/U=;
h=From:To:Subject:Date:From;
b=rP3L1k0qLVC0/CwPSqPvBj5rK9I0c9G2DzBJw963AEa8kckpuZ8naWQEnQRhwP6TV
oA5qxX5QSdKNdwSU/Z6HyRu5v8ehP+n366lTkXRLXsoJ0UAZUmrZxeGqZuKvVXg7kC
I1GbovbD8fpIkiqAuzef4zm/fqpmiPbur3lCP4xYc9rUojCRISCIKnWPJHLCggg03I
JqD9bI3NiKMNZz6PH08Or5FPzPpCfoLXaSYSN8fLS0E3o/P1ulDO/i85HZsjbpzvqf
0fvcyH3Ayr6gWzOEmsgiBhgyNXnqD6my+t/6rFYDht2ncQjoKQNClBoVxwzSDA+Npa
TGA8N9K+TPu3g==
From: Eshel Yaron <me@HIDDEN>
X-Hashcash: 1:20:240206:bug-gnu-emacs@HIDDEN::bjYdasTK/itmQBUE:34q1
Date: Tue, 06 Feb 2024 21:17:45 +0100
Message-ID: <m1h6ilgxee.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
Received-SPF: pass client-ip=107.175.124.16; envelope-from=me@HIDDEN;
helo=eshelyaron.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, SPF_HELO_PASS=-0.001,
SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 0.9 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.1 (/)
--=-=-=
Content-Type: text/plain
Tags: patch
Hello Dmitry, All,
This patch adds support for bookmarking "*xref*" buffers and restoring
them later, even across Emacs sessions.
To make this happen, we need to propagate some more information to the
"*xref*" buffer (and any other Xref fronted). We do this, without
breaking compatibility, by setting a new variable from inside the xrefs
fetcher function. The frontend can examine this variable to learn all
about the source of the fetched xrefs after invoking the fetcher.
Namely, the "*xref*" buffer uses this information to create bookmarks.
WDYT?
--=-=-=
Content-Type: text/patch
Content-Disposition: attachment;
filename=0001-Support-bookmarking-Xref-results-buffers.patch
From 62f76297ec240df8101ab47fa4a89fa584b7f05c Mon Sep 17 00:00:00 2001
From: Eshel Yaron <me@HIDDEN>
Date: Tue, 6 Feb 2024 20:33:53 +0100
Subject: [PATCH] Support bookmarking Xref results buffers
* lisp/progmodes/xref.el (bookmark-make-record-default)
(bookmark-make-record, bookmark-prop-get)
(bookmark-handle-bookmark, bookmark-get-rear-context-string)
(bookmark-get-front-context-string): Declare functions.
(xref-backend-context, xref-backend-restore): New generic functions.
(xref--backend, xref--identifier, xref--kind)
(xref--original-buffer, xref--original-point): New local variables.
(xref--show-common-initialize): Set them in Xref results buffer.
(xref-default-bookmark-name-format): New user option.
(xref-bookmark-make-record, xref-bookmark-jump): New functions.
(xref--xref-buffer-mode): Set 'bookmark-make-record-function'.
(xref-fetcher-alist): New variable.
(xref--show-xref-buffer, xref-show-definitions-buffer)
(xref-show-definitions-buffer-at-bottom): Use it.
(xref--read-identifier): Improve error message.
(xref-make-fetcher): Extract from...
(xref--create-fetcher): ...here.
* doc/emacs/maintaining.texi (Xref Commands): Document new feature.
* etc/NEWS: Announce new feature and Xref generic functions.
---
doc/emacs/maintaining.texi | 4 +
etc/NEWS | 12 +++
lisp/progmodes/xref.el | 166 +++++++++++++++++++++++++++++++++----
3 files changed, 165 insertions(+), 17 deletions(-)
diff --git a/doc/emacs/maintaining.texi b/doc/emacs/maintaining.texi
index d3e06fa697b..dd3fb3c2dd2 100644
--- a/doc/emacs/maintaining.texi
+++ b/doc/emacs/maintaining.texi
@@ -2466,6 +2466,10 @@ Xref Commands
@kbd{C-n}, and @kbd{C-p} are available for moving around the buffer
without displaying the references.
+You can also bookmark the @file{*xref*} buffer with @kbd{C-x r m} and
+restore it from the same state later by jumping to that bookmark with
+@kbd{C-x r b}. @xref{Bookmarks}.
+
@node Identifier Search
@subsubsection Searching and Replacing with Identifiers
@cindex search and replace in multiple source files
diff --git a/etc/NEWS b/etc/NEWS
index f980d612a57..a33a0e9855b 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -437,6 +437,11 @@ This mode now emits 'wheel-up/down/right/left' events instead of
It uses the 'mouse-wheel-up/down/left/right-event'
variables to decide which button maps to which wheel event (if any).
+** Xref
+
++++
+*** You can now bookmark (and later restore) "*xref*" buffers.
+
** Info
---
@@ -1664,6 +1669,13 @@ styles to skip eager fontification of completion candidates, which
improves performance. Such a Lisp program can then use the
'completion-lazy-hilit' function to fontify candidates just in time.
+** New Xref generic functions for recording and restoring context.
+Xref backends can now implement the generic function
+'xref-backend-context' to change how Xref records the context used for
+fetching cross-references when bookmarking Xref results for later use.
+In addition, the new generic function 'xref-backend-restore' lets
+backends change how Xref then restores this context.
+
** Functions and variables to transpose sexps
+++
diff --git a/lisp/progmodes/xref.el b/lisp/progmodes/xref.el
index 717b837a2e5..249e018eb56 100644
--- a/lisp/progmodes/xref.el
+++ b/lisp/progmodes/xref.el
@@ -314,6 +314,21 @@ xref-backend-identifier-completion-ignore-case
"Return t if case is not significant in identifier completion."
completion-ignore-case)
+(declare-function bookmark-make-record "bookmark")
+(declare-function bookmark-make-record-default "bookmark")
+(declare-function bookmark-prop-get "bookmark")
+(declare-function bookmark-handle-bookmark "bookmark")
+(declare-function bookmark-get-rear-context-string "bookmark")
+(declare-function bookmark-get-front-context-string "bookmark")
+
+(cl-defgeneric xref-backend-context (_backend _identifier _kind)
+ "Return BACKEND-specific context for finding references to IDENTIFIER."
+ (bookmark-make-record))
+
+(cl-defgeneric xref-backend-restore (_backend context)
+ "Restore BACKEND-specific CONTEXT."
+ (bookmark-handle-bookmark context))
+
;;; misc utilities
(defun xref--alistify (list key)
@@ -671,6 +686,23 @@ xref--original-window
(defvar-local xref--fetcher nil
"The original function to call to fetch the list of xrefs.")
+(defvar-local xref--backend nil
+ "The backend that produced the xrefs that the current buffer is showing.")
+
+(defvar-local xref--identifier nil
+ "The identifier for which the current buffer is showing xrefs.")
+
+(defvar-local xref--kind nil
+ "The kind of xrefs the current buffer is showing.")
+
+(defvar-local xref--original-buffer nil
+ "Buffer in which the Xref command that created this buffer was called.")
+
+(defvar-local xref--original-point nil
+ "Position in which the Xref command that created this buffer was called.
+
+See also `xref--original-buffer'.")
+
(defun xref--show-pos-in-buf (pos buf)
"Goto and display position POS of buffer BUF in a window.
Honor `xref--original-window-intent', run `xref-after-jump-hook'
@@ -997,6 +1029,63 @@ xref--xref-buffer-mode-map
(define-key map (kbd "M-,") #'xref-quit-and-pop-marker-stack)
map))
+(defcustom xref-default-bookmark-name-format "%i %k"
+ "Format of the default bookmark name for Xref buffer bookmarks.
+
+The default bookmark name is the value of this option (a string), with
+\"%i\" sequences substituted for the identifier that the Xref buffer is
+showing information about, \"%k\" substituted with the kind of
+information shown (\"references\", \"definitions\", etc.), and \"%b\"
+substituted for the name of the backend that produced the information."
+ :type 'string
+ :version "30.1")
+
+(defun xref-bookmark-make-record ()
+ "Return a bookmark record for bookmarking the current Xref buffer.
+
+This function is used as the value of `bookmark-make-record-function' in
+Xref buffers."
+ (unless xref--backend
+ (user-error "Cannot bookmark due to unknown Xref backend"))
+ `(,(format-spec xref-default-bookmark-name-format
+ `((?i . ,xref--identifier)
+ (?k . ,xref--kind)
+ (?b . ,xref--backend)))
+ ,@(bookmark-make-record-default t)
+ (backend . ,xref--backend)
+ (context . ,(when (buffer-live-p xref--original-buffer)
+ (with-current-buffer xref--original-buffer
+ (save-excursion
+ (ignore-errors (goto-char xref--original-point))
+ (xref-backend-context xref--backend
+ xref--identifier
+ xref--kind)))))
+ (identifier . ,xref--identifier)
+ (kind . ,xref--kind)
+ (handler . xref-bookmark-jump)))
+
+(defun xref-bookmark-jump (bookmark)
+ "Jump to Xref buffer bookmark BOOKMARK."
+ (let* ((backend (bookmark-prop-get bookmark 'backend))
+ (context (bookmark-prop-get bookmark 'context))
+ (identifier (bookmark-prop-get bookmark 'identifier))
+ (kind (bookmark-prop-get bookmark 'kind))
+ (fetcher (save-current-buffer
+ (xref-backend-restore backend context)
+ (xref-make-fetcher backend identifier kind identifier
+ (current-buffer) (point))))
+ (xref-auto-jump-to-first-xref nil))
+ (set-buffer (xref--show-xref-buffer fetcher nil))
+ (let ((forward-str (bookmark-get-front-context-string bookmark))
+ (behind-str (bookmark-get-rear-context-string bookmark)))
+ (when (and forward-str (search-forward forward-str (point-max) t))
+ (goto-char (match-beginning 0)))
+ (when (and behind-str (search-backward behind-str (point-min) t))
+ (goto-char (match-end 0)))
+ nil)))
+
+(put 'xref-bookmark-jump 'bookmark-handler-type "Xref")
+
(declare-function outline-search-text-property "outline"
(property &optional value bound move backward looking-at))
@@ -1017,7 +1106,8 @@ xref--xref-buffer-mode
(lambda (&optional bound move backward looking-at)
(outline-search-text-property
'xref-group nil bound move backward looking-at)))
- (setq-local outline-level (lambda () 1)))
+ (setq-local outline-level (lambda () 1))
+ (setq-local bookmark-make-record-function #'xref-bookmark-make-record))
(defvar xref--transient-buffer-mode-map
(let ((map (make-sparse-keymap)))
@@ -1235,11 +1325,29 @@ xref--ensure-default-directory
0 nil
(lambda () (with-current-buffer buffer (setq default-directory dd)))))
+(defvar xref-fetcher-alist nil
+ "Alist with information about the last used Xref fetcher function.
+
+Fetcher functions which Xref passes to `xref-show-xrefs-function' set
+this variable to an alist with the following key-value pairs:
+
+- (backend . BACKEND) where BACKEND is the Xref backend that the
+ fetcher invokes.
+- (identifier . ID) where ID is the identifier for which the fetcher
+ fetches references.
+- (kind . KIND) where KIND is the kind of references that the fetcher
+ fetches.
+- (original-buffer . BUF) where BUF is the buffer in which the Xref
+ command that created the fetcher was invoked.
+- (original-point . POS) where POS is the buffer position in which the
+ Xref command that created the fetcher was invoked.")
+
(defun xref--show-xref-buffer (fetcher alist)
(cl-assert (functionp fetcher))
(let* ((xrefs
(or
(assoc-default 'fetched-xrefs alist)
+ (setq xref-fetcher-alist nil)
(funcall fetcher)))
(xref-alist (xref--analyze xrefs))
(dd default-directory)
@@ -1247,7 +1355,7 @@ xref--show-xref-buffer
(with-current-buffer (get-buffer-create xref-buffer-name)
(xref--ensure-default-directory dd (current-buffer))
(xref--xref-buffer-mode)
- (xref--show-common-initialize xref-alist fetcher alist)
+ (xref--show-common-initialize xref-alist fetcher (append xref-fetcher-alist alist))
(setq xref-num-matches-found (length xrefs))
(setq mode-line-process (list xref-mode-line-matches))
(pop-to-buffer (current-buffer))
@@ -1272,7 +1380,12 @@ xref--show-common-initialize
(add-hook 'post-command-hook 'xref--apply-truncation nil t)
(goto-char (point-min))
(setq xref--original-window (assoc-default 'window alist)
- xref--original-window-intent (assoc-default 'display-action alist))
+ xref--original-window-intent (assoc-default 'display-action alist)
+ xref--original-buffer (assoc-default 'original-buffer alist)
+ xref--original-point (assoc-default 'original-point alist)
+ xref--backend (assoc-default 'backend alist)
+ xref--identifier (assoc-default 'identifier alist)
+ xref--kind (assoc-default 'kind alist))
(setq xref--fetcher fetcher)))
(defun xref-revert-buffer ()
@@ -1310,6 +1423,7 @@ xref-show-definitions-buffer
"Show the definitions list in a regular window.
When only one definition found, jump to it right away instead."
+ (setq xref-fetcher-alist nil)
(let ((xrefs (funcall fetcher))
buf)
(cond
@@ -1333,6 +1447,7 @@ xref-show-definitions-buffer-at-bottom
When there is more than one definition, split the selected window
and show the list in a small window at the bottom. And use a
local keymap that binds `RET' to `xref-quit-and-goto-xref'."
+ (setq xref-fetcher-alist nil)
(let* ((xrefs (funcall fetcher))
(dd default-directory)
;; XXX: Make percentage customizable maybe?
@@ -1353,7 +1468,7 @@ xref-show-definitions-buffer-at-bottom
(with-current-buffer (get-buffer-create xref-buffer-name)
(xref--ensure-default-directory dd (current-buffer))
(xref--transient-buffer-mode)
- (xref--show-common-initialize xref-alist fetcher alist)
+ (xref--show-common-initialize xref-alist fetcher (append xref-fetcher-alist alist))
(pop-to-buffer (current-buffer)
`(display-buffer-in-direction . ((direction . below)
(window-height . ,size-fun))))
@@ -1552,7 +1667,7 @@ xref--read-identifier
nil nil nil
'xref--read-identifier-history def t)))
(if (equal id "")
- (or def (user-error "There is no default identifier"))
+ (or def (user-error "No default identifier"))
id)))
(t def))))
@@ -1569,16 +1684,23 @@ xref--find-definitions
(xref--create-fetcher id 'definitions id)
display-action))
-(defun xref--create-fetcher (input kind arg)
- "Return an xref list fetcher function.
+(defun xref-make-fetcher (backend input kind identifier buffer point)
+ "Return fetcher function for xrefs of kind KIND for IDENTIFIER using BACKEND.
-It revisits the saved position and delegates the finding logic to
-the xref backend method indicated by KIND and passes ARG to it."
- (let* ((orig-buffer (current-buffer))
- (orig-position (point))
- (backend (xref-find-backend))
- (method (intern (format "xref-backend-%s" kind))))
+INPUT is the user input for the Xref operation, usually it is the same
+as IDENTIFIER, but the two may differ when KIND is `apropos'. BUFFER
+and POINT are the buffer and specific position in which the xref
+operation was invoked.
+
+The fetcher function returns a list of xrefs, and sets
+`xref-fetcher-alist', which see."
+ (let ((method (intern (format "xref-backend-%s" kind))))
(lambda ()
+ (setq xref-fetcher-alist (list (cons 'original-buffer buffer)
+ (cons 'original-point point)
+ (cons 'backend backend)
+ (cons 'identifier identifier)
+ (cons 'kind kind)))
(save-excursion
;; Xref methods are generally allowed to depend on the text
;; around point, not just on their explicit arguments.
@@ -1586,14 +1708,24 @@ xref--create-fetcher
;; There is only so much we can do, however, to recreate that
;; context, given that the user is free to change the buffer
;; contents freely in the meantime.
- (when (buffer-live-p orig-buffer)
- (set-buffer orig-buffer)
- (ignore-errors (goto-char orig-position)))
- (let ((xrefs (funcall method backend arg)))
+ (when (buffer-live-p buffer)
+ (set-buffer buffer)
+ (ignore-errors (goto-char point)))
+ (let ((xrefs (funcall method backend identifier)))
(unless xrefs
(xref--not-found-error kind input))
xrefs)))))
+(defun xref--create-fetcher (input kind arg)
+ "Return an xref list fetcher function.
+
+It revisits the saved position and delegates the finding logic to
+the xref backend method indicated by KIND and passes ARG to it."
+ (xref-make-fetcher (xref-find-backend)
+ input kind arg
+ (current-buffer)
+ (copy-marker (point))))
+
(defun xref--not-found-error (kind input)
(user-error "No %s found for: %s" (symbol-name kind) input))
--
2.42.0
--=-=-=--
Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.505 (Entity 5.505) Content-Type: text/plain; charset=utf-8 X-Loop: help-debbugs@HIDDEN From: help-debbugs@HIDDEN (GNU bug Tracking System) To: Eshel Yaron <me@HIDDEN> Subject: bug#68958: Acknowledgement ([PATCH] Support bookmarking Xref results buffers) Message-ID: <handler.68958.B.170725070210259.ack <at> debbugs.gnu.org> References: <m1h6ilgxee.fsf@HIDDEN> X-Gnu-PR-Message: ack 68958 X-Gnu-PR-Package: emacs X-Gnu-PR-Keywords: patch Reply-To: 68958 <at> debbugs.gnu.org Date: Tue, 06 Feb 2024 20:19:02 +0000 Thank you for filing a new bug report with debbugs.gnu.org. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. As you requested using X-Debbugs-CC, your message was also forwarded to Dmitry Gutov <dmitry@HIDDEN> (after having been given a bug report number, if it did not have one). Your message has been sent to the package maintainer(s): bug-gnu-emacs@HIDDEN If you wish to submit further information on this problem, please send it to 68958 <at> debbugs.gnu.org. Please do not send mail to help-debbugs@HIDDEN unless you wish to report a problem with the Bug-tracking system. --=20 68958: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D68958 GNU Bug Tracking System Contact help-debbugs@HIDDEN with problems
X-Loop: help-debbugs@HIDDEN
Subject: bug#68958: [PATCH] Support bookmarking Xref results buffers
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 07 Feb 2024 12:27:02 +0000
Resent-Message-ID: <handler.68958.B68958.170730876526241 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 68958
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Eshel Yaron <me@HIDDEN>
Cc: dmitry@HIDDEN, 68958 <at> debbugs.gnu.org
Received: via spool by 68958-submit <at> debbugs.gnu.org id=B68958.170730876526241
(code B ref 68958); Wed, 07 Feb 2024 12:27:02 +0000
Received: (at 68958) by debbugs.gnu.org; 7 Feb 2024 12:26:05 +0000
Received: from localhost ([127.0.0.1]:55826 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1rXh08-0006pB-Ip
for submit <at> debbugs.gnu.org; Wed, 07 Feb 2024 07:26:05 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:52876)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <eliz@HIDDEN>) id 1rXh03-0006oa-Ik
for 68958 <at> debbugs.gnu.org; Wed, 07 Feb 2024 07:26:03 -0500
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 <eliz@HIDDEN>)
id 1rXgzk-0008M4-6e; Wed, 07 Feb 2024 07:25:40 -0500
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=s6fIWV0EG2bn0bUkurH+IW69zsLFzXhuBkIwIY45ATI=; b=JhDS5ezioQ5/
tqSrqEfahxDp66d+c9ZeqTHS2wJMSMVwWCThwi5DpSIf0b0X6pD0hhmcWWj07GjAneZSIErhGCqxQ
/AYi6KDE2WOm/99mdkdSBoZgG4eWBJD0gHCD9n7rkfkmaxvBDJ95HRGnkAxuuZ80xP9TcUJ+TnOAF
OVzs4wEM2B5An9SGDKd4jxBFtcIyB0WrMQpDNitTzXaFHzlCPGApMQpH8qmHKiaRfcYATLZ5bTFSZ
VdnKEHiXSPvKTi4k0xMjzfMy74pFj1ajfMY1ZNe8pOgnEOGajNRa00xRwymj8ze+/ninWukN5BNlI
Xum+zlFVki8J7gJ12oromg==;
Date: Wed, 07 Feb 2024 14:25:36 +0200
Message-Id: <86le7wzcjj.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <m1h6ilgxee.fsf@HIDDEN> (bug-gnu-emacs@HIDDEN)
References: <m1h6ilgxee.fsf@HIDDEN>
X-Spam-Score: -1.6 (-)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.6 (--)
> Cc: Dmitry Gutov <dmitry@HIDDEN>
> Date: Tue, 06 Feb 2024 21:17:45 +0100
> From: Eshel Yaron via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN>
>
> This patch adds support for bookmarking "*xref*" buffers and restoring
> them later, even across Emacs sessions.
>
> To make this happen, we need to propagate some more information to the
> "*xref*" buffer (and any other Xref fronted). We do this, without
> breaking compatibility, by setting a new variable from inside the xrefs
> fetcher function. The frontend can examine this variable to learn all
> about the source of the fetched xrefs after invoking the fetcher.
> Namely, the "*xref*" buffer uses this information to create bookmarks.
Thanks. Frankly, I'm surprised we need such a complex changeset for
supporting such a simple extension, but I'll let Dmitry judge that.
> --- a/doc/emacs/maintaining.texi
> +++ b/doc/emacs/maintaining.texi
> @@ -2466,6 +2466,10 @@ Xref Commands
> @kbd{C-n}, and @kbd{C-p} are available for moving around the buffer
> without displaying the references.
>
> +You can also bookmark the @file{*xref*} buffer with @kbd{C-x r m} and
> +restore it from the same state later by jumping to that bookmark with
> +@kbd{C-x r b}. @xref{Bookmarks}.
Since "C-x r m" and "C-x r b" are bookmark commands, they should not
be described here; instead, its description in "Bookmarks" should
mention any special features related to the Xref buffers (not that I
see what is there to mention, but maybe I'm missing something). If
you think this capability is worth mentioning in the "Xref Commands"
node, you should do it in passage, like
You can bookmark and restore your place in @file{*xref*} buffers,
see @ref{Bookmarks}.
> +** New Xref generic functions for recording and restoring context.
> +Xref backends can now implement the generic function
> +'xref-backend-context' to change how Xref records the context used for
> +fetching cross-references when bookmarking Xref results for later use.
> +In addition, the new generic function 'xref-backend-restore' lets
> +backends change how Xref then restores this context.
I'm not sure this is for NEWS. Either expand the documentation, place
it in the ELisp manual, and just mention the function's name in NEWS,
or simply don't mention it in NEWS.
X-Loop: help-debbugs@HIDDEN
Subject: bug#68958: [PATCH] Support bookmarking Xref results buffers
Resent-From: Eshel Yaron <me@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 07 Feb 2024 17:05:02 +0000
Resent-Message-ID: <handler.68958.B68958.170732548413149 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 68958
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Eli Zaretskii <eliz@HIDDEN>
Cc: dmitry@HIDDEN, 68958 <at> debbugs.gnu.org
Received: via spool by 68958-submit <at> debbugs.gnu.org id=B68958.170732548413149
(code B ref 68958); Wed, 07 Feb 2024 17:05:02 +0000
Received: (at 68958) by debbugs.gnu.org; 7 Feb 2024 17:04:44 +0000
Received: from localhost ([127.0.0.1]:57798 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1rXlLn-0003Q0-MH
for submit <at> debbugs.gnu.org; Wed, 07 Feb 2024 12:04:44 -0500
Received: from mail.eshelyaron.com ([107.175.124.16]:56732 helo=eshelyaron.com)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <me@HIDDEN>) id 1rXlLl-0003Ps-E2
for 68958 <at> debbugs.gnu.org; Wed, 07 Feb 2024 12:04:42 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eshelyaron.com;
s=mail; t=1707325466;
bh=bDpt816oz8NxhmNk++moG9syt1gxz02sRZooU5DBSa8=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=MaQXJos/2VzZxPD4bfwB4BdmP8LNPqAbac7dGqou7gtvbkXUsnCfve0h+SSK8Q010
Puz9tIj88vFIF8atGeaqvkx6wiL2EBvackNVBHEacuh6wYXqP46CIHNojE+LoBVJ3a
+1N6XYHoDfx12bF55TerBlbaNdMcBr/OPxu0lvnGkv7yMxFCQ5cy8V5w6oCEXm6+PE
XrL1npAnJU+kHSU/Bny9zyHf6Wv2bNoTeaXrNO/M+VdvvBHsreyGEopLm7QU2smsq6
CnY/fXkio0PlOjnrnrfP+lVt41CXo4bKOTk6YE9QS5arpTpGcHlsgk7KfK93MDNkyg
vx2Wnq0ATBCcQ==
From: Eshel Yaron <me@HIDDEN>
In-Reply-To: <86le7wzcjj.fsf@HIDDEN> (Eli Zaretskii's message of "Wed, 07 Feb
2024 14:25:36 +0200")
References: <m1h6ilgxee.fsf@HIDDEN> <86le7wzcjj.fsf@HIDDEN>
Date: Wed, 07 Feb 2024 18:04:24 +0100
Message-ID: <m17cjgxl2f.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-Spam-Score: 0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.3 (/)
--=-=-=
Content-Type: text/plain
Eli Zaretskii <eliz@HIDDEN> writes:
>> Cc: Dmitry Gutov <dmitry@HIDDEN>
>> Date: Tue, 06 Feb 2024 21:17:45 +0100
>> From: Eshel Yaron via "Bug reports for GNU Emacs,
>> the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN>
>>
>> This patch adds support for bookmarking "*xref*" buffers and restoring
>> them later, even across Emacs sessions.
>>
>> To make this happen, we need to propagate some more information to the
>> "*xref*" buffer (and any other Xref fronted). We do this, without
>> breaking compatibility, by setting a new variable from inside the xrefs
>> fetcher function. The frontend can examine this variable to learn all
>> about the source of the fetched xrefs after invoking the fetcher.
>> Namely, the "*xref*" buffer uses this information to create bookmarks.
>
> Thanks. Frankly, I'm surprised we need such a complex changeset for
> supporting such a simple extension, but I'll let Dmitry judge that.
Thanks for taking a look.
It's a simple extension, but unless I'm missing something in the code,
the Xref infrastructure needs these extra tweaks to accommodate for it.
>> --- a/doc/emacs/maintaining.texi
>> +++ b/doc/emacs/maintaining.texi
>> @@ -2466,6 +2466,10 @@ Xref Commands
>> @kbd{C-n}, and @kbd{C-p} are available for moving around the buffer
>> without displaying the references.
>>
>> +You can also bookmark the @file{*xref*} buffer with @kbd{C-x r m} and
>> +restore it from the same state later by jumping to that bookmark with
>> +@kbd{C-x r b}. @xref{Bookmarks}.
>
> Since "C-x r m" and "C-x r b" are bookmark commands, they should not
> be described here; instead, its description in "Bookmarks" should
> mention any special features related to the Xref buffers (not that I
> see what is there to mention, but maybe I'm missing something). If
> you think this capability is worth mentioning in the "Xref Commands"
> node, you should do it in passage, like
>
> You can bookmark and restore your place in @file{*xref*} buffers,
> see @ref{Bookmarks}.
That makes sense. I updated the text accordingly in the attached patch.
>> +** New Xref generic functions for recording and restoring context.
>> +Xref backends can now implement the generic function
>> +'xref-backend-context' to change how Xref records the context used for
>> +fetching cross-references when bookmarking Xref results for later use.
>> +In addition, the new generic function 'xref-backend-restore' lets
>> +backends change how Xref then restores this context.
>
> I'm not sure this is for NEWS. Either expand the documentation, place
> it in the ELisp manual, and just mention the function's name in NEWS,
> or simply don't mention it in NEWS.
All right, I removed this bit.
Here's the updated patch (v2):
--=-=-=
Content-Type: text/x-patch
Content-Disposition: attachment;
filename=v2-0001-Support-bookmarking-Xref-results-buffers.patch
From 51b748c4dd97cb60e7328b6510e8dd55da4a75ce Mon Sep 17 00:00:00 2001
From: Eshel Yaron <me@HIDDEN>
Date: Tue, 6 Feb 2024 20:33:53 +0100
Subject: [PATCH v2] Support bookmarking Xref results buffers
* lisp/progmodes/xref.el (bookmark-make-record-default)
(bookmark-make-record, bookmark-prop-get)
(bookmark-handle-bookmark, bookmark-get-rear-context-string)
(bookmark-get-front-context-string): Declare functions.
(xref-backend-context, xref-backend-restore): New generic functions.
(xref--backend, xref--identifier, xref--kind)
(xref--original-buffer, xref--original-point): New local variables.
(xref--show-common-initialize): Set them in Xref results buffer.
(xref-default-bookmark-name-format): New user option.
(xref-bookmark-make-record, xref-bookmark-jump): New functions.
(xref--xref-buffer-mode): Set 'bookmark-make-record-function'.
(xref-fetcher-alist): New variable.
(xref--show-xref-buffer, xref-show-definitions-buffer)
(xref-show-definitions-buffer-at-bottom): Use it.
(xref--read-identifier): Improve error message.
(xref-make-fetcher): Extract from...
(xref--create-fetcher): ...here.
* doc/emacs/maintaining.texi (Xref Commands): Document new feature.
* etc/NEWS: Announce it. (Bug#68958)
---
doc/emacs/maintaining.texi | 3 +
etc/NEWS | 5 ++
lisp/progmodes/xref.el | 166 +++++++++++++++++++++++++++++++++----
3 files changed, 157 insertions(+), 17 deletions(-)
diff --git a/doc/emacs/maintaining.texi b/doc/emacs/maintaining.texi
index d3e06fa697b..4cd02851594 100644
--- a/doc/emacs/maintaining.texi
+++ b/doc/emacs/maintaining.texi
@@ -2466,6 +2466,9 @@ Xref Commands
@kbd{C-n}, and @kbd{C-p} are available for moving around the buffer
without displaying the references.
+You can bookmark and restore your place in @file{*xref*} buffers, see
+@ref{Bookmarks}.
+
@node Identifier Search
@subsubsection Searching and Replacing with Identifiers
@cindex search and replace in multiple source files
diff --git a/etc/NEWS b/etc/NEWS
index f980d612a57..500433ff955 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -437,6 +437,11 @@ This mode now emits 'wheel-up/down/right/left' events instead of
It uses the 'mouse-wheel-up/down/left/right-event'
variables to decide which button maps to which wheel event (if any).
+** Xref
+
++++
+*** You can now bookmark (and later restore) "*xref*" buffers.
+
** Info
---
diff --git a/lisp/progmodes/xref.el b/lisp/progmodes/xref.el
index 717b837a2e5..249e018eb56 100644
--- a/lisp/progmodes/xref.el
+++ b/lisp/progmodes/xref.el
@@ -314,6 +314,21 @@ xref-backend-identifier-completion-ignore-case
"Return t if case is not significant in identifier completion."
completion-ignore-case)
+(declare-function bookmark-make-record "bookmark")
+(declare-function bookmark-make-record-default "bookmark")
+(declare-function bookmark-prop-get "bookmark")
+(declare-function bookmark-handle-bookmark "bookmark")
+(declare-function bookmark-get-rear-context-string "bookmark")
+(declare-function bookmark-get-front-context-string "bookmark")
+
+(cl-defgeneric xref-backend-context (_backend _identifier _kind)
+ "Return BACKEND-specific context for finding references to IDENTIFIER."
+ (bookmark-make-record))
+
+(cl-defgeneric xref-backend-restore (_backend context)
+ "Restore BACKEND-specific CONTEXT."
+ (bookmark-handle-bookmark context))
+
;;; misc utilities
(defun xref--alistify (list key)
@@ -671,6 +686,23 @@ xref--original-window
(defvar-local xref--fetcher nil
"The original function to call to fetch the list of xrefs.")
+(defvar-local xref--backend nil
+ "The backend that produced the xrefs that the current buffer is showing.")
+
+(defvar-local xref--identifier nil
+ "The identifier for which the current buffer is showing xrefs.")
+
+(defvar-local xref--kind nil
+ "The kind of xrefs the current buffer is showing.")
+
+(defvar-local xref--original-buffer nil
+ "Buffer in which the Xref command that created this buffer was called.")
+
+(defvar-local xref--original-point nil
+ "Position in which the Xref command that created this buffer was called.
+
+See also `xref--original-buffer'.")
+
(defun xref--show-pos-in-buf (pos buf)
"Goto and display position POS of buffer BUF in a window.
Honor `xref--original-window-intent', run `xref-after-jump-hook'
@@ -997,6 +1029,63 @@ xref--xref-buffer-mode-map
(define-key map (kbd "M-,") #'xref-quit-and-pop-marker-stack)
map))
+(defcustom xref-default-bookmark-name-format "%i %k"
+ "Format of the default bookmark name for Xref buffer bookmarks.
+
+The default bookmark name is the value of this option (a string), with
+\"%i\" sequences substituted for the identifier that the Xref buffer is
+showing information about, \"%k\" substituted with the kind of
+information shown (\"references\", \"definitions\", etc.), and \"%b\"
+substituted for the name of the backend that produced the information."
+ :type 'string
+ :version "30.1")
+
+(defun xref-bookmark-make-record ()
+ "Return a bookmark record for bookmarking the current Xref buffer.
+
+This function is used as the value of `bookmark-make-record-function' in
+Xref buffers."
+ (unless xref--backend
+ (user-error "Cannot bookmark due to unknown Xref backend"))
+ `(,(format-spec xref-default-bookmark-name-format
+ `((?i . ,xref--identifier)
+ (?k . ,xref--kind)
+ (?b . ,xref--backend)))
+ ,@(bookmark-make-record-default t)
+ (backend . ,xref--backend)
+ (context . ,(when (buffer-live-p xref--original-buffer)
+ (with-current-buffer xref--original-buffer
+ (save-excursion
+ (ignore-errors (goto-char xref--original-point))
+ (xref-backend-context xref--backend
+ xref--identifier
+ xref--kind)))))
+ (identifier . ,xref--identifier)
+ (kind . ,xref--kind)
+ (handler . xref-bookmark-jump)))
+
+(defun xref-bookmark-jump (bookmark)
+ "Jump to Xref buffer bookmark BOOKMARK."
+ (let* ((backend (bookmark-prop-get bookmark 'backend))
+ (context (bookmark-prop-get bookmark 'context))
+ (identifier (bookmark-prop-get bookmark 'identifier))
+ (kind (bookmark-prop-get bookmark 'kind))
+ (fetcher (save-current-buffer
+ (xref-backend-restore backend context)
+ (xref-make-fetcher backend identifier kind identifier
+ (current-buffer) (point))))
+ (xref-auto-jump-to-first-xref nil))
+ (set-buffer (xref--show-xref-buffer fetcher nil))
+ (let ((forward-str (bookmark-get-front-context-string bookmark))
+ (behind-str (bookmark-get-rear-context-string bookmark)))
+ (when (and forward-str (search-forward forward-str (point-max) t))
+ (goto-char (match-beginning 0)))
+ (when (and behind-str (search-backward behind-str (point-min) t))
+ (goto-char (match-end 0)))
+ nil)))
+
+(put 'xref-bookmark-jump 'bookmark-handler-type "Xref")
+
(declare-function outline-search-text-property "outline"
(property &optional value bound move backward looking-at))
@@ -1017,7 +1106,8 @@ xref--xref-buffer-mode
(lambda (&optional bound move backward looking-at)
(outline-search-text-property
'xref-group nil bound move backward looking-at)))
- (setq-local outline-level (lambda () 1)))
+ (setq-local outline-level (lambda () 1))
+ (setq-local bookmark-make-record-function #'xref-bookmark-make-record))
(defvar xref--transient-buffer-mode-map
(let ((map (make-sparse-keymap)))
@@ -1235,11 +1325,29 @@ xref--ensure-default-directory
0 nil
(lambda () (with-current-buffer buffer (setq default-directory dd)))))
+(defvar xref-fetcher-alist nil
+ "Alist with information about the last used Xref fetcher function.
+
+Fetcher functions which Xref passes to `xref-show-xrefs-function' set
+this variable to an alist with the following key-value pairs:
+
+- (backend . BACKEND) where BACKEND is the Xref backend that the
+ fetcher invokes.
+- (identifier . ID) where ID is the identifier for which the fetcher
+ fetches references.
+- (kind . KIND) where KIND is the kind of references that the fetcher
+ fetches.
+- (original-buffer . BUF) where BUF is the buffer in which the Xref
+ command that created the fetcher was invoked.
+- (original-point . POS) where POS is the buffer position in which the
+ Xref command that created the fetcher was invoked.")
+
(defun xref--show-xref-buffer (fetcher alist)
(cl-assert (functionp fetcher))
(let* ((xrefs
(or
(assoc-default 'fetched-xrefs alist)
+ (setq xref-fetcher-alist nil)
(funcall fetcher)))
(xref-alist (xref--analyze xrefs))
(dd default-directory)
@@ -1247,7 +1355,7 @@ xref--show-xref-buffer
(with-current-buffer (get-buffer-create xref-buffer-name)
(xref--ensure-default-directory dd (current-buffer))
(xref--xref-buffer-mode)
- (xref--show-common-initialize xref-alist fetcher alist)
+ (xref--show-common-initialize xref-alist fetcher (append xref-fetcher-alist alist))
(setq xref-num-matches-found (length xrefs))
(setq mode-line-process (list xref-mode-line-matches))
(pop-to-buffer (current-buffer))
@@ -1272,7 +1380,12 @@ xref--show-common-initialize
(add-hook 'post-command-hook 'xref--apply-truncation nil t)
(goto-char (point-min))
(setq xref--original-window (assoc-default 'window alist)
- xref--original-window-intent (assoc-default 'display-action alist))
+ xref--original-window-intent (assoc-default 'display-action alist)
+ xref--original-buffer (assoc-default 'original-buffer alist)
+ xref--original-point (assoc-default 'original-point alist)
+ xref--backend (assoc-default 'backend alist)
+ xref--identifier (assoc-default 'identifier alist)
+ xref--kind (assoc-default 'kind alist))
(setq xref--fetcher fetcher)))
(defun xref-revert-buffer ()
@@ -1310,6 +1423,7 @@ xref-show-definitions-buffer
"Show the definitions list in a regular window.
When only one definition found, jump to it right away instead."
+ (setq xref-fetcher-alist nil)
(let ((xrefs (funcall fetcher))
buf)
(cond
@@ -1333,6 +1447,7 @@ xref-show-definitions-buffer-at-bottom
When there is more than one definition, split the selected window
and show the list in a small window at the bottom. And use a
local keymap that binds `RET' to `xref-quit-and-goto-xref'."
+ (setq xref-fetcher-alist nil)
(let* ((xrefs (funcall fetcher))
(dd default-directory)
;; XXX: Make percentage customizable maybe?
@@ -1353,7 +1468,7 @@ xref-show-definitions-buffer-at-bottom
(with-current-buffer (get-buffer-create xref-buffer-name)
(xref--ensure-default-directory dd (current-buffer))
(xref--transient-buffer-mode)
- (xref--show-common-initialize xref-alist fetcher alist)
+ (xref--show-common-initialize xref-alist fetcher (append xref-fetcher-alist alist))
(pop-to-buffer (current-buffer)
`(display-buffer-in-direction . ((direction . below)
(window-height . ,size-fun))))
@@ -1552,7 +1667,7 @@ xref--read-identifier
nil nil nil
'xref--read-identifier-history def t)))
(if (equal id "")
- (or def (user-error "There is no default identifier"))
+ (or def (user-error "No default identifier"))
id)))
(t def))))
@@ -1569,16 +1684,23 @@ xref--find-definitions
(xref--create-fetcher id 'definitions id)
display-action))
-(defun xref--create-fetcher (input kind arg)
- "Return an xref list fetcher function.
+(defun xref-make-fetcher (backend input kind identifier buffer point)
+ "Return fetcher function for xrefs of kind KIND for IDENTIFIER using BACKEND.
-It revisits the saved position and delegates the finding logic to
-the xref backend method indicated by KIND and passes ARG to it."
- (let* ((orig-buffer (current-buffer))
- (orig-position (point))
- (backend (xref-find-backend))
- (method (intern (format "xref-backend-%s" kind))))
+INPUT is the user input for the Xref operation, usually it is the same
+as IDENTIFIER, but the two may differ when KIND is `apropos'. BUFFER
+and POINT are the buffer and specific position in which the xref
+operation was invoked.
+
+The fetcher function returns a list of xrefs, and sets
+`xref-fetcher-alist', which see."
+ (let ((method (intern (format "xref-backend-%s" kind))))
(lambda ()
+ (setq xref-fetcher-alist (list (cons 'original-buffer buffer)
+ (cons 'original-point point)
+ (cons 'backend backend)
+ (cons 'identifier identifier)
+ (cons 'kind kind)))
(save-excursion
;; Xref methods are generally allowed to depend on the text
;; around point, not just on their explicit arguments.
@@ -1586,14 +1708,24 @@ xref--create-fetcher
;; There is only so much we can do, however, to recreate that
;; context, given that the user is free to change the buffer
;; contents freely in the meantime.
- (when (buffer-live-p orig-buffer)
- (set-buffer orig-buffer)
- (ignore-errors (goto-char orig-position)))
- (let ((xrefs (funcall method backend arg)))
+ (when (buffer-live-p buffer)
+ (set-buffer buffer)
+ (ignore-errors (goto-char point)))
+ (let ((xrefs (funcall method backend identifier)))
(unless xrefs
(xref--not-found-error kind input))
xrefs)))))
+(defun xref--create-fetcher (input kind arg)
+ "Return an xref list fetcher function.
+
+It revisits the saved position and delegates the finding logic to
+the xref backend method indicated by KIND and passes ARG to it."
+ (xref-make-fetcher (xref-find-backend)
+ input kind arg
+ (current-buffer)
+ (copy-marker (point))))
+
(defun xref--not-found-error (kind input)
(user-error "No %s found for: %s" (symbol-name kind) input))
--
2.42.0
--=-=-=--
X-Loop: help-debbugs@HIDDEN
Subject: bug#68958: [PATCH] Support bookmarking Xref results buffers
Resent-From: Juri Linkov <juri@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 07 Feb 2024 17:48:04 +0000
Resent-Message-ID: <handler.68958.B68958.170732806117144 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 68958
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: 68958 <at> debbugs.gnu.org
Cc: Dmitry Gutov <dmitry@HIDDEN>, Eshel Yaron <me@HIDDEN>
Received: via spool by 68958-submit <at> debbugs.gnu.org id=B68958.170732806117144
(code B ref 68958); Wed, 07 Feb 2024 17:48:04 +0000
Received: (at 68958) by debbugs.gnu.org; 7 Feb 2024 17:47:41 +0000
Received: from localhost ([127.0.0.1]:57858 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1rXm1N-0004SS-3S
for submit <at> debbugs.gnu.org; Wed, 07 Feb 2024 12:47:41 -0500
Received: from relay8-d.mail.gandi.net ([217.70.183.201]:46375)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <juri@HIDDEN>) id 1rXm1L-0004SD-Qt
for 68958 <at> debbugs.gnu.org; Wed, 07 Feb 2024 12:47:40 -0500
Received: by mail.gandi.net (Postfix) with ESMTPSA id E435C1BF206;
Wed, 7 Feb 2024 17:47:18 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
In-Reply-To: <m1h6ilgxee.fsf@HIDDEN> (Eshel Yaron via's message of
"Tue, 06 Feb 2024 21:17:45 +0100")
Organization: LINKOV.NET
References: <m1h6ilgxee.fsf@HIDDEN>
Date: Wed, 07 Feb 2024 19:25:48 +0200
Message-ID: <868r3wi57v.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain
X-GND-Sasl: juri@HIDDEN
X-Spam-Score: -0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)
> This patch adds support for bookmarking "*xref*" buffers and restoring
> them later, even across Emacs sessions.
Shouldn't 'revert-buffer-function' in the xref buffer
be sufficient to reconstruct the buffer contents?
Usually modes set buffer-local 'revert-buffer-function'
to a lambda that reruns the top function with previous
arguments. But it seems xref.el doesn't set it.
I once tried to use 'revert-buffer-function' to restore
xref buffers from the desktop, but abandoned the idea.
Not because xref.el doesn't set 'revert-buffer-function'.
But because it would take too much time to restore
the desktop while it will rerun all saved xref buffers.
OTOH, saving an xref bookmark makes more sense.
And probably your patch will help to implement
'revert-buffer-function' for xref as well.
X-Loop: help-debbugs@HIDDEN
Subject: bug#68958: [PATCH] Support bookmarking Xref results buffers
Resent-From: Dmitry Gutov <dmitry@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 11 Feb 2024 03:22:02 +0000
Resent-Message-ID: <handler.68958.B68958.170762171420127 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 68958
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Juri Linkov <juri@HIDDEN>, 68958 <at> debbugs.gnu.org
Cc: Eshel Yaron <me@HIDDEN>
Received: via spool by 68958-submit <at> debbugs.gnu.org id=B68958.170762171420127
(code B ref 68958); Sun, 11 Feb 2024 03:22:02 +0000
Received: (at 68958) by debbugs.gnu.org; 11 Feb 2024 03:21:54 +0000
Received: from localhost ([127.0.0.1]:40851 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1rZ0Pi-0005EZ-8F
for submit <at> debbugs.gnu.org; Sat, 10 Feb 2024 22:21:54 -0500
Received: from wout1-smtp.messagingengine.com ([64.147.123.24]:49631)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <dmitry@HIDDEN>) id 1rZ0Pf-0005EA-VL
for 68958 <at> debbugs.gnu.org; Sat, 10 Feb 2024 22:21:53 -0500
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45])
by mailout.west.internal (Postfix) with ESMTP id 9A9D732001C6;
Sat, 10 Feb 2024 22:21:29 -0500 (EST)
Received: from mailfrontend1 ([10.202.2.162])
by compute5.internal (MEProxy); Sat, 10 Feb 2024 22:21:29 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc
:cc:content-transfer-encoding:content-type:content-type:date
:date:from:from:in-reply-to:in-reply-to:message-id:mime-version
:references:reply-to:subject:subject:to:to; s=fm2; t=1707621689;
x=1707708089; bh=BVv3Fm478+wtxY51jQBNqAj0JZUFVQivfk5KqN1WaKk=; b=
dhN/LNZ5nehmGigz+8h6waXLH53kQiVVn5iAcFFH2mxgcCT/fOmt3x7RVjqYeqqs
za8XfRtJc2Rl62J04gYMxZMyJATns40C2S9t5a7TuvpDQdcy6Eem+ARxR8py61fU
mbIgMVckwIim64BXKqclltBtE2nA44ihz6sHkmcPX20k1qGViN+sb9o/8OHt9MrD
ecar4uwdUTaVhMyFbZd7wAgmJ6kBuGVonFYz2Q3KM4FbbiQSDh0jcQtU/tcJtGbj
tg8EtDFZLpVIr5jABOYSkM6PbkYAOvyMhJP6JNqSuQCaaZVZjhA4RCmqByYDhk4d
VFeFMW/ahBanybdQlkrE9g==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
messagingengine.com; h=cc:cc:content-transfer-encoding
:content-type:content-type:date:date:feedback-id:feedback-id
:from:from:in-reply-to:in-reply-to:message-id:mime-version
:references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy
:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1707621689; x=
1707708089; bh=BVv3Fm478+wtxY51jQBNqAj0JZUFVQivfk5KqN1WaKk=; b=s
lGiP2me1gH2Qjcut2qMaqqQ3yzxetjG9LiOY06iuqhYH+fcxAilGXD9+dmzGp48A
O7VcGoCBmvK8rSt9A5LQf6gk/TgxWplz7Isn/Kd6m0G3NizYYk0EW9r4EpmHzhHM
fx4ZWS5UCBBAdcWbT38vR+bj1OTMySjs3XKQ/e2PqqzLTwcn6LO1ynpk8SEQ4KPy
+prjTvGuD1DPkcCFR2r9EyRn0zkF2q0ZzUIRKf2TFo00FwxbIipVsYsCEa3feVrr
HhGEGVA1BhmSJ5XKTmgMlHGJIHMJdwRwrdu7/iTkTX8WIetfbgKsggMs1pyufxHP
ZiAYHGP7ZkS6/h4JGpp1g==
X-ME-Sender: <xms:OD3IZRg6QXfs4hmrzrbG0UMO7Ls2HJP_I6iXos2b4rWcYH0eDuZxmw>
<xme:OD3IZWBoDQcTHqPhPLi__xozj32KGOchLB0AWdlVNFWanmuE3BLurOz7BVI06C2rd
Bq_nAEeQRrxc2nh-Vg>
X-ME-Received: <xmr:OD3IZREJXHxpwURfmMu5Ya8FTatBWUhrcmBYcG9YiiIgJFAAJmO1zwXL6XinbT4LWghA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledruddtgdehlecutefuodetggdotefrodftvf
curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu
uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc
fjughrpefkffggfgfuvfevfhfhjggtgfesthejredttddvjeenucfhrhhomhepffhmihht
rhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrghtth
gvrhhnpeetudeljeegheetgfehgeejkeeuhedvveeikeeufedtvddtveefhfdvveegudej
heenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumh
hithhrhiesghhuthhovhdruggvvh
X-ME-Proxy: <xmx:OD3IZWSO5AFmAHnM2VLsKDczvDKiTBgSIgVeWOJGuJDSEFFFMU5gbw>
<xmx:OD3IZew8sl7sbBVcSiMZwnPoQkyAHJltbyu9CdYzEaJBy7Vf5iaD4A>
<xmx:OD3IZc6UFscPkWZUFbq-l7Z3xjTdPlPEBDPdt_6mDcNU8xQdO75ePg>
<xmx:OT3IZTqCsf7C-KpTJ4wXCbwfNjokRdWMUCas04-x3de6sLbAwOyOiw>
Feedback-ID: i0e71465a:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat,
10 Feb 2024 22:21:27 -0500 (EST)
Message-ID: <53a9fafc-7b2a-485e-b6c1-df3f372b60e2@HIDDEN>
Date: Sun, 11 Feb 2024 05:21:25 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
References: <m1h6ilgxee.fsf@HIDDEN> <868r3wi57v.fsf@HIDDEN>
From: Dmitry Gutov <dmitry@HIDDEN>
In-Reply-To: <868r3wi57v.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
On 07/02/2024 19:25, Juri Linkov wrote:
>> This patch adds support for bookmarking "*xref*" buffers and restoring
>> them later, even across Emacs sessions.
>
> Shouldn't 'revert-buffer-function' in the xref buffer
> be sufficient to reconstruct the buffer contents?
>
> Usually modes set buffer-local 'revert-buffer-function'
> to a lambda that reruns the top function with previous
> arguments. But it seems xref.el doesn't set it.
I can't find my original cause for not using this variable here, so if
replacing the command xref-revert-buffer with setting
revert-buffer-function makes things easier for someone, I'm all for it.
> I once tried to use 'revert-buffer-function' to restore
> xref buffers from the desktop, but abandoned the idea.
> Not because xref.el doesn't set 'revert-buffer-function'.
> But because it would take too much time to restore
> the desktop while it will rerun all saved xref buffers.
>
> OTOH, saving an xref bookmark makes more sense.
> And probably your patch will help to implement
> 'revert-buffer-function' for xref as well.
I don't think bookmark would save the whole buffer contents. Would it?
Otherwise, re-running the search(es) seems inevitable.
X-Loop: help-debbugs@HIDDEN
Subject: bug#68958: [PATCH] Support bookmarking Xref results buffers
Resent-From: Dmitry Gutov <dmitry@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 11 Feb 2024 03:28:01 +0000
Resent-Message-ID: <handler.68958.B68958.170762207421280 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 68958
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Eli Zaretskii <eliz@HIDDEN>, Eshel Yaron <me@HIDDEN>
Cc: 68958 <at> debbugs.gnu.org
Received: via spool by 68958-submit <at> debbugs.gnu.org id=B68958.170762207421280
(code B ref 68958); Sun, 11 Feb 2024 03:28:01 +0000
Received: (at 68958) by debbugs.gnu.org; 11 Feb 2024 03:27:54 +0000
Received: from localhost ([127.0.0.1]:41332 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1rZ0VV-0005XA-Mz
for submit <at> debbugs.gnu.org; Sat, 10 Feb 2024 22:27:54 -0500
Received: from wout1-smtp.messagingengine.com ([64.147.123.24]:43933)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <dmitry@HIDDEN>) id 1rZ0VT-0005Wj-S2
for 68958 <at> debbugs.gnu.org; Sat, 10 Feb 2024 22:27:52 -0500
Received: from compute6.internal (compute6.nyi.internal [10.202.2.47])
by mailout.west.internal (Postfix) with ESMTP id 0EE773200A5A;
Sat, 10 Feb 2024 22:27:29 -0500 (EST)
Received: from mailfrontend1 ([10.202.2.162])
by compute6.internal (MEProxy); Sat, 10 Feb 2024 22:27:30 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc
:cc:content-transfer-encoding:content-type:content-type:date
:date:from:from:in-reply-to:in-reply-to:message-id:mime-version
:references:reply-to:subject:subject:to:to; s=fm2; t=1707622049;
x=1707708449; bh=pUBULLhWYS0/oZQO9gWgKZDuQONs2xFPRMh/hgOj1eM=; b=
I3dXTP/fy0aH4vJtkrnelQF/2x/7oeWJWivsruGq7yF5TfVwttmo2OZ8eRV4n+Lf
SW5EGuWaWpc2oKq/LrfIUe5TANsD+YDWVkt5pCFEAQf0mJse/6pbb8xzpwpzsAN6
vND8jx8VYpoKt2z69LjvDOPokj7gdVEYzAats8i/cAezAEqipqo/3PYnvhakumHQ
xHELNoSsgdrCLl0yCFOzX28B19nHkk+2Jj3epnGxjlf41gpYIA5MO4NPXSiP01iC
/Igyjg6Spx9IzvoFPxk45fq+prhw8rxmw3fu3yz7/zFzRtkGu+8AwiQ7ndC5HzzW
dX7CKwuwByeXI1xN9ijlOw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
messagingengine.com; h=cc:cc:content-transfer-encoding
:content-type:content-type:date:date:feedback-id:feedback-id
:from:from:in-reply-to:in-reply-to:message-id:mime-version
:references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy
:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1707622049; x=
1707708449; bh=pUBULLhWYS0/oZQO9gWgKZDuQONs2xFPRMh/hgOj1eM=; b=s
/uu+OmQD+hNylVOf6UEKRENQTwXFCYytYyCLHuevbhMEHyuhZ3ujH2XtuExPJgiM
Iytr70ePx6pNpBN7xfa27FZWne4nABLPUhHv+eFNcct760kNUED3QlD/zt4vU/45
OizIQWFHrU2Aiu3ZjvXjDGzj9RT5X+RXxAGB07zJ6u8g1yZYAFauwsWNn9pUKCec
rLr3eyMM13FZFfAlGlFMguEO90Uf3jm/8PZafUwwhBa4EvasajkCUa5s7/XDI0Y8
G1WUcbxAFClUGwRrpzREpPJ7+JTSYsYbBx1R8Sm/J/azW4GTuxOV2aDlb53VfhI/
eQKae57tl1aacExfvEdQw==
X-ME-Sender: <xms:oT7IZRP7cKJVVOk1lGGP34u6axfuQbrkcb_rHH8Bgd2p_CnrKMoQAw>
<xme:oT7IZT8VKOML3qEc3Vsk3kZJTyaOg_gbFIWoz9s8x7yv-n6e-hy_6GkI61_Ybug3L
xwTUiGxBdJpFFo62rQ>
X-ME-Received: <xmr:oT7IZQT-m-ocBP7CH3kmvxfOzDU1R1pIHZLtaLxGB2BfFjxIsUAQtAjV7ipDKh9V1Znd>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledruddtgdeitdcutefuodetggdotefrodftvf
curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu
uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc
fjughrpefkffggfgfuvfevfhfhjggtgfesthejredttddvjeenucfhrhhomhepffhmihht
rhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrghtth
gvrhhnpeetudeljeegheetgfehgeejkeeuhedvveeikeeufedtvddtveefhfdvveegudej
heenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumh
hithhrhiesghhuthhovhdruggvvh
X-ME-Proxy: <xmx:oT7IZdsrNvOhkl60ee8gFjxe094CVOWFUq_NAhHLUF9KQJZIfSp4Xw>
<xmx:oT7IZZcyn83V1oCSLsZy0izGQtxNBhSpTCqFNpp7d_qHivToIxT1BQ>
<xmx:oT7IZZ3QVqpur9qjVvg_ig5SMawfQcKvj1fOl6HOBmG3h7YQlrxrtQ>
<xmx:oT7IZZG3NnZzJ1vvn6rIeUrGTyYsRNl33fmTlAYHMuCus_ESNbhMvg>
Feedback-ID: i0e71465a:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat,
10 Feb 2024 22:27:28 -0500 (EST)
Message-ID: <0b3f4669-180e-466f-96f3-7eeae994581f@HIDDEN>
Date: Sun, 11 Feb 2024 05:27:27 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
References: <m1h6ilgxee.fsf@HIDDEN> <86le7wzcjj.fsf@HIDDEN>
From: Dmitry Gutov <dmitry@HIDDEN>
In-Reply-To: <86le7wzcjj.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
On 07/02/2024 14:25, Eli Zaretskii wrote:
>> To make this happen, we need to propagate some more information to the
>> "*xref*" buffer (and any other Xref fronted). We do this, without
>> breaking compatibility, by setting a new variable from inside the xrefs
>> fetcher function. The frontend can examine this variable to learn all
>> about the source of the fetched xrefs after invoking the fetcher.
>> Namely, the "*xref*" buffer uses this information to create bookmarks.
> Thanks. Frankly, I'm surprised we need such a complex changeset for
> supporting such a simple extension, but I'll let Dmitry judge that.
A lot of changes seem to stem from the desire to add detailed info into
the bookmarks's name (including the identifier being searched, the
search type, and the xref backend in use).
At the moment our code doesn't save all of those separately, just
combines them in xref--fetcher.
So whether the patch has to be complex would depend on whether we really
need to have bookmark names look exactly like proposed. Though I'd
rewrite it a little even in that case.
X-Loop: help-debbugs@HIDDEN
Subject: bug#68958: [PATCH] Support bookmarking Xref results buffers
Resent-From: Eshel Yaron <me@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 11 Feb 2024 06:26:02 +0000
Resent-Message-ID: <handler.68958.B68958.170763272119344 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 68958
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Dmitry Gutov <dmitry@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, 68958 <at> debbugs.gnu.org
Received: via spool by 68958-submit <at> debbugs.gnu.org id=B68958.170763272119344
(code B ref 68958); Sun, 11 Feb 2024 06:26:02 +0000
Received: (at 68958) by debbugs.gnu.org; 11 Feb 2024 06:25:21 +0000
Received: from localhost ([127.0.0.1]:52060 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1rZ3HE-00051s-JT
for submit <at> debbugs.gnu.org; Sun, 11 Feb 2024 01:25:21 -0500
Received: from mail.eshelyaron.com ([107.175.124.16]:53084 helo=eshelyaron.com)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <me@HIDDEN>) id 1rZ3BL-0004mM-Rx
for 68958 <at> debbugs.gnu.org; Sun, 11 Feb 2024 01:19:16 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eshelyaron.com;
s=mail; t=1707632339;
bh=e1mKQb3C9/2QmITpwGW5FtezikoKrcDubMNdZeS3NUA=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=i3gP/Z021uTSCEELpQ1BNQnqe/ecCT1f5Fu0vzOzV/KSBbxl3XszhPrqnX3AgSvNm
fuyH0MFludVYUexaCf95AMs8srd6Hf29WZgh4o/+NqnUhH9FQUGp7NrxtQruUVoCiI
NSdhNAzc3j4AlJsHfRL1HKfF3HNO3IHsuy4CDCAqIvOlx7Yj8xUnD8hfS21Q+R0imn
HGW630JHa5d4LDCve+kXhIZSUPJy3kmamvlfD3Gf3CTZuIWGnhm3uVdvrQ9+3OhhR6
rc77PMjAGrivppADMp6R9dTap7Ol6TLdFA34lE+dmrAyjt+gszEKESyrsVaq/7WtRt
OjfUr0D5mZMTA==
From: Eshel Yaron <me@HIDDEN>
In-Reply-To: <0b3f4669-180e-466f-96f3-7eeae994581f@HIDDEN> (Dmitry Gutov's
message of "Sun, 11 Feb 2024 05:27:27 +0200")
References: <m1h6ilgxee.fsf@HIDDEN> <86le7wzcjj.fsf@HIDDEN>
<0b3f4669-180e-466f-96f3-7eeae994581f@HIDDEN>
Date: Sun, 11 Feb 2024 07:18:56 +0100
Message-ID: <m1cyt35xrj.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.3 (/)
Hi,
Dmitry Gutov <dmitry@HIDDEN> writes:
> On 07/02/2024 14:25, Eli Zaretskii wrote:
>>> To make this happen, we need to propagate some more information to the
>>> "*xref*" buffer (and any other Xref fronted). We do this, without
>>> breaking compatibility, by setting a new variable from inside the xrefs
>>> fetcher function. The frontend can examine this variable to learn all
>>> about the source of the fetched xrefs after invoking the fetcher.
>>> Namely, the "*xref*" buffer uses this information to create bookmarks.
>> Thanks. Frankly, I'm surprised we need such a complex changeset for
>> supporting such a simple extension, but I'll let Dmitry judge that.
>
> A lot of changes seem to stem from the desire to add detailed info
> into the bookmarks's name (including the identifier being searched,
> the search type, and the xref backend in use).
That's not the case. The changes are all meant to facilitate creating
bookmarks that you can restore at a later session. AFAICT the backend,
identifier and search type (kind) are a required for that, no? We use
them to suggest a meaningful bookmark name, but that's just a bonus.
> At the moment our code doesn't save all of those separately, just
> combines them in xref--fetcher.
>
> So whether the patch has to be complex would depend on whether we
> really need to have bookmark names look exactly like proposed. Though
> I'd rewrite it a little even in that case.
Again, the name of the bookmark is really not the focus here. We can't
persist the value of xref--fetcher, since it's an anonymous function, so
we get all the info needed to /recreate/ that function to the frontend.
If there's another (simpler?) way to provide this feature, please do tell.
Best,
Eshel
X-Loop: help-debbugs@HIDDEN
Subject: bug#68958: [PATCH] Support bookmarking Xref results buffers
Resent-From: Eshel Yaron <me@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 11 Feb 2024 11:23:01 +0000
Resent-Message-ID: <handler.68958.B68958.170765057726102 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 68958
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Dmitry Gutov <dmitry@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, 68958 <at> debbugs.gnu.org
Received: via spool by 68958-submit <at> debbugs.gnu.org id=B68958.170765057726102
(code B ref 68958); Sun, 11 Feb 2024 11:23:01 +0000
Received: (at 68958) by debbugs.gnu.org; 11 Feb 2024 11:22:57 +0000
Received: from localhost ([127.0.0.1]:40325 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1rZ7vE-0006mv-Rn
for submit <at> debbugs.gnu.org; Sun, 11 Feb 2024 06:22:57 -0500
Received: from mail.eshelyaron.com ([107.175.124.16]:49466 helo=eshelyaron.com)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <me@HIDDEN>) id 1rZ7uy-0006m6-37
for 68958 <at> debbugs.gnu.org; Sun, 11 Feb 2024 06:22:55 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eshelyaron.com;
s=mail; t=1707650023;
bh=xg/m9qIqCDgejKVl2K5z2LZow8YXl1/tvG7IBKec6wE=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=jfDHG7QLhYeR+5k2t45BTZN3RUcsnUUPyWB8Dl4Yw6PbdamnWfCIvbwjK2JPxz519
EqMFB5BWM6u36xu9PSyB0H4ehn+Eb0dMXeGznB8BhfU8KXO3TxfPThd6Oco5MhTFmW
9VzeQeiEjdc7KlMpuBGAvxwQqQq7XgdMmmXXp8Jd23t/x69B312zGyXu6TCK7OIAAc
Zyj+pAWXZ10wN4cpLjIA3LIKYgySCYBlkA0XkcSNqBBLcMn0X72ATcrwwDOl3bi6/F
1F5Vo5eQiBwRlmhkmnaSSDQ3emVolGa4gtuwBGLo1rULk9pdaigFMuQK/KLcJ3XdFu
Rc4SYrXppFi8A==
From: Eshel Yaron <me@HIDDEN>
In-Reply-To: <m1cyt35xrj.fsf@HIDDEN> (Eshel Yaron's message of "Sun,
11 Feb 2024 07:18:56 +0100")
References: <m1h6ilgxee.fsf@HIDDEN> <86le7wzcjj.fsf@HIDDEN>
<0b3f4669-180e-466f-96f3-7eeae994581f@HIDDEN>
<m1cyt35xrj.fsf@HIDDEN>
Date: Sun, 11 Feb 2024 12:13:40 +0100
Message-ID: <m1r0hj2qzf.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.3 (/)
I wrote:
> Dmitry Gutov <dmitry@HIDDEN> writes:
>
>> A lot of changes seem to stem from the desire to add detailed info
>> into the bookmarks's name (including the identifier being searched,
>> the search type, and the xref backend in use).
>
> That's not the case. The changes are all meant to facilitate creating
> bookmarks that you can restore at a later session. AFAICT the backend,
> identifier and search type (kind) are a required for that, no? We use
> them to suggest a meaningful bookmark name, but that's just a bonus.
>
>> At the moment our code doesn't save all of those separately, just
>> combines them in xref--fetcher.
>>
>> So whether the patch has to be complex would depend on whether we
>> really need to have bookmark names look exactly like proposed. Though
>> I'd rewrite it a little even in that case.
>
> Again, the name of the bookmark is really not the focus here. We can't
> persist the value of xref--fetcher, since it's an anonymous function, so
> we get all the info needed to /recreate/ that function to the frontend.
> If there's another (simpler?) way to provide this feature, please do tell.
Perhaps I can explain the reasoning behind this patch a little better:
The goal is to be able to persistently save (bookmark) your state in an
*xref* results buffer, perhaps as part of a long refactoring effort for
some code base, and restore it later, perhaps in another Emacs session.
Basically we want the following to work:
1. Use M-? to get a list of references in the *xref* buffer.
2. Do something with some of them, but not all.
3. Hit C-x r m to bookmark your position.
4. Quit the *xref* buffer, and close Emacs.
5. Open Emacs again, type C-x r b and select a bookmark to get an *xref* buffer
corresponding to the same search as before, with point on the same
reference that you where on when you created the bookmark, if possible.
Crucially, looking at step 3, we need to have the data needed to create
such a persistent bookmark available in the *xref* buffer, long after
the execution of the command that created this buffer. So, what data do
we need? IIUC, to replicate the saved search we need to invoke the same
backend, with the same type of search, for the same input. Since Xref
backends may (and do) use the position of point and other buffer context
to guide the search, we want to preserve and restore that extra context
as well.
So in this patch, we add the new xref-fetcher-alist variable that allows
the fetcher function to communicate all this information to the
frontend, so when we create the *xref* buffer we can store it in
buffer-local variables, and then use them to create a bookmark record
when the user types C-x r m. This record includes all of the data
needed to perform the same Xref search in a new Emacs session, and in
most cases to get back to same position. We also let the backend
override what extra context exactly gets saved and restored, and how.
Hope this makes it clearer :)
X-Loop: help-debbugs@HIDDEN
Subject: bug#68958: [PATCH] Support bookmarking Xref results buffers
Resent-From: Dmitry Gutov <dmitry@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 11 Feb 2024 15:36:02 +0000
Resent-Message-ID: <handler.68958.B68958.170766572415835 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 68958
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Eshel Yaron <me@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, 68958 <at> debbugs.gnu.org
Received: via spool by 68958-submit <at> debbugs.gnu.org id=B68958.170766572415835
(code B ref 68958); Sun, 11 Feb 2024 15:36:02 +0000
Received: (at 68958) by debbugs.gnu.org; 11 Feb 2024 15:35:24 +0000
Received: from localhost ([127.0.0.1]:55546 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1rZBrY-00047L-E9
for submit <at> debbugs.gnu.org; Sun, 11 Feb 2024 10:35:24 -0500
Received: from wout3-smtp.messagingengine.com ([64.147.123.19]:45977)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <dmitry@HIDDEN>) id 1rZBrX-000472-BH
for 68958 <at> debbugs.gnu.org; Sun, 11 Feb 2024 10:35:23 -0500
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41])
by mailout.west.internal (Postfix) with ESMTP id 0048B32003D3;
Sun, 11 Feb 2024 10:35:00 -0500 (EST)
Received: from mailfrontend1 ([10.202.2.162])
by compute1.internal (MEProxy); Sun, 11 Feb 2024 10:35:01 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc
:cc:content-transfer-encoding:content-type:content-type:date
:date:from:from:in-reply-to:in-reply-to:message-id:mime-version
:references:reply-to:subject:subject:to:to; s=fm2; t=1707665700;
x=1707752100; bh=kxHskxZmPZsQbrDUPM6S6T1SVDLzVWV/Nvty54tKtlI=; b=
EY200NdzlLfSdrjgzd8OInHaIQ0A37SfRiPrCWfxZI/UHyACcd6WcxuaqdoKhZ2y
82k9gCCyvcBYXQGmoYGYDEQY5Wf+ATvsIwZp5iCxjwSZqhVmL7ADUVKhJ1IIZo9t
JQ6SBnAr5lRXqbN7jTFkeuuCWnCm2jqcWgSTvaQe+TTZ18s4lsgUWIPRa59QuvVX
moFwedjPtlug0O8gf2lptciyc9e9odCY3RjPr+8C3R6imi9Bahls2m2R3Fpb65sl
jEN9HPlCgIT2dbCPEV4eGEbkZuXOuOgvDA/NCkiPNZxFXTLdSPAhmybgbQbxVyPk
3qmeWWNtUu8mj0fJZc0wCg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
messagingengine.com; h=cc:cc:content-transfer-encoding
:content-type:content-type:date:date:feedback-id:feedback-id
:from:from:in-reply-to:in-reply-to:message-id:mime-version
:references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy
:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1707665700; x=
1707752100; bh=kxHskxZmPZsQbrDUPM6S6T1SVDLzVWV/Nvty54tKtlI=; b=A
Jhz5KbO4nWWAvrO6Be3fBJw9jGIj8AKupEEtXpR4Vxow66LVAhHm6OdK70ZeDHgC
oMKsEHZyCKju1p/L4PeFid2g79OK69hL2Z0rSXqUPBmGv2HCo4O7OWuUoJbrHL05
kyBKCx5l/a1Rh/ldY1nVugozMUBqopvLvn6XTjX6NgGkF2peRfUF/b9LLFtOU6S6
1l4VrfgnhcAbEUWSSmhfCf9S9AWZx7m2KeBFVb/mf4+NKTjw8iynlrQ/fUhaz//T
vWFjI5Pu4l9421O6QxQUTFj8la675e2DGaXTHQEv9vFE7t0Ljbddk+fIsKhL737P
L/IHlGLGfWsToLH/FcQ8Q==
X-ME-Sender: <xms:JOnIZWRqSjpr3EdQhcerLIlj287f8kZ9KvvRYTjv7WSshPszcP4AKA>
<xme:JOnIZbxAa8HN60cvS1p27NO2aZ1J4NIBWPvjs36sDxqlGefgfz9ZRS3cbIMY6ncRo
KlKvaZJU1fJKE5Vgas>
X-ME-Received: <xmr:JOnIZT3Qg2OURdGU37oIcBkhvwITfDopK478-asZqj5ZGYMx81JjBK9zfV5BgY0Wuf5_>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledruddugdejlecutefuodetggdotefrodftvf
curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu
uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc
fjughrpefkffggfgfuvfevfhfhjggtgfesthejredttddvjeenucfhrhhomhepffhmihht
rhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrghtth
gvrhhnpeetudeljeegheetgfehgeejkeeuhedvveeikeeufedtvddtveefhfdvveegudej
heenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumh
hithhrhiesghhuthhovhdruggvvh
X-ME-Proxy: <xmx:JOnIZSDkVe9Y2Plzu8DwTFWPzfJ9WR1Cr2cXomW-pbRnwGuNAUHwsg>
<xmx:JOnIZfilSlyXDs_l-EMEO6Ir2xSj-0V2KDBrea9Wj7mShEZyB412mg>
<xmx:JOnIZeoWbO64mNXEaoXX9poalcKHPzj-fUsNJ5rqG8xtSS20bTL4zQ>
<xmx:JOnIZXZTuSaDMQruW7zaJQvtrNaONdbAtYPVHTxpw2UHdruTxc_Tdg>
Feedback-ID: i0e71465a:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun,
11 Feb 2024 10:34:59 -0500 (EST)
Message-ID: <b521e786-377c-4834-be68-87a824ae6384@HIDDEN>
Date: Sun, 11 Feb 2024 17:34:57 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
References: <m1h6ilgxee.fsf@HIDDEN> <86le7wzcjj.fsf@HIDDEN>
<0b3f4669-180e-466f-96f3-7eeae994581f@HIDDEN>
<m1cyt35xrj.fsf@HIDDEN>
From: Dmitry Gutov <dmitry@HIDDEN>
In-Reply-To: <m1cyt35xrj.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
On 11/02/2024 08:18, Eshel Yaron wrote:
> Again, the name of the bookmark is really not the focus here. We can't
> persist the value of xref--fetcher, since it's an anonymous function, so
> we get all the info needed to /recreate/ that function to the frontend.
> If there's another (simpler?) way to provide this feature, please do tell.
All right, that's a good point.
Could we really not persist an anonymous function, though? It can be
printed and, I suppose, evaluated. At least in theory, whatever links it
has to containing lexical contexts, should be possible to "detach" when
writing the literal to disk, to be read later.
The issue with doing this at the level of xref--create-fetcher, is that
the addition becomes specific to the Xref searches only (find
definitions/references), and the more generic Xref UI infrastructure
remains unsupported (such as 'M-x project-find-regexp' or whatever calls
to xref-show-xrefs exist in third-party packages) -- so those Xref
buffers would remain not bookmark-able, or they will each require
specialized code like the one you proposed here.
X-Loop: help-debbugs@HIDDEN
Subject: bug#68958: [PATCH] Support bookmarking Xref results buffers
Resent-From: Eshel Yaron <me@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 11 Feb 2024 17:22:02 +0000
Resent-Message-ID: <handler.68958.B68958.1707672086859 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 68958
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Dmitry Gutov <dmitry@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, 68958 <at> debbugs.gnu.org
Received: via spool by 68958-submit <at> debbugs.gnu.org id=B68958.1707672086859
(code B ref 68958); Sun, 11 Feb 2024 17:22:02 +0000
Received: (at 68958) by debbugs.gnu.org; 11 Feb 2024 17:21:26 +0000
Received: from localhost ([127.0.0.1]:33259 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1rZDWA-0000Di-0l
for submit <at> debbugs.gnu.org; Sun, 11 Feb 2024 12:21:26 -0500
Received: from mail.eshelyaron.com ([107.175.124.16]:40254 helo=eshelyaron.com)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <me@HIDDEN>) id 1rZDW6-0000DV-1m
for 68958 <at> debbugs.gnu.org; Sun, 11 Feb 2024 12:21:24 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eshelyaron.com;
s=mail; t=1707672065;
bh=qNAdPofz1b0NPexdwDKkqxl/22gnzUoJIgr3Jx8TJr0=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=ZBUa2nb6pXg6TYqhIaMl2vgtQz59Z2SVaCmMuqhcPkfmNVExFlLCiHM8ix4Nqp3OD
7kR5hhEJ1GNeez6qWeqrDEoW8ufGBV6QAPnyBhN47L9cFTBha2+UqDyJJUP1OTergB
7Lgo37EAvT8/rLydE0ZIk0f/VeAcLq2OEstEXUIqikNWdSMmGMb9R5CNK2BwxZIqPr
sNHU5dfBoTfoZLZD67IZaTTTNBqke7Xj4hzXxPQD2P7L6aY66frIwVbhr7nqY/cXQb
s6eIRxO2r+vczfRL/gyGNl6xRfeJ/uwpDr2hejXQEmnMfoSx1Tv4puOItUrZLP8MT6
FtN036e+M8PHw==
From: Eshel Yaron <me@HIDDEN>
In-Reply-To: <b521e786-377c-4834-be68-87a824ae6384@HIDDEN> (Dmitry Gutov's
message of "Sun, 11 Feb 2024 17:34:57 +0200")
References: <m1h6ilgxee.fsf@HIDDEN> <86le7wzcjj.fsf@HIDDEN>
<0b3f4669-180e-466f-96f3-7eeae994581f@HIDDEN>
<m1cyt35xrj.fsf@HIDDEN>
<b521e786-377c-4834-be68-87a824ae6384@HIDDEN>
Date: Sun, 11 Feb 2024 18:21:02 +0100
Message-ID: <m14jee5341.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.3 (/)
Dmitry Gutov <dmitry@HIDDEN> writes:
> On 11/02/2024 08:18, Eshel Yaron wrote:
>
>> Again, the name of the bookmark is really not the focus here. We can't
>> persist the value of xref--fetcher, since it's an anonymous function, so
>> we get all the info needed to /recreate/ that function to the frontend.
>> If there's another (simpler?) way to provide this feature, please do tell.
>
> All right, that's a good point.
>
> Could we really not persist an anonymous function, though? It can be
> printed and, I suppose, evaluated. At least in theory, whatever links
> it has to containing lexical contexts, should be possible to "detach"
> when writing the literal to disk, to be read later.
I'm not sure. It certainly cant' work for arbitrary function objects
(say, if you create a function with 'make_function' in a module).
>
> The issue with doing this at the level of xref--create-fetcher, is
> that the addition becomes specific to the Xref searches only (find
> definitions/references), and the more generic Xref UI infrastructure
> remains unsupported (such as 'M-x project-find-regexp' or whatever
> calls to xref-show-xrefs exist in third-party packages) -- so those
> Xref buffers would remain not bookmark-able, or they will each require
> specialized code like the one you proposed here.
Yes, but such callers of xref-show-xrefs can implement the same API to
have the corresponding *xref* buffer bookmark-able. Namely, arrange for
the fetcher function to populate xref-fetcher-alist with relevant data.
Indeed, I plan to work on doing that for project-find-regexp next. If
we had a solution that doesn't require any work from third party to
benefit from this new feature, that'd be even better, of course. But
since the current API to Xref frontends accepts any fetcher function,
I'm not sure that's possible...
X-Loop: help-debbugs@HIDDEN
Subject: bug#68958: [PATCH] Support bookmarking Xref results buffers
Resent-From: Juri Linkov <juri@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 11 Feb 2024 17:56:02 +0000
Resent-Message-ID: <handler.68958.B68958.17076741207337 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 68958
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Dmitry Gutov <dmitry@HIDDEN>
Cc: Eshel Yaron <me@HIDDEN>, 68958 <at> debbugs.gnu.org
Received: via spool by 68958-submit <at> debbugs.gnu.org id=B68958.17076741207337
(code B ref 68958); Sun, 11 Feb 2024 17:56:02 +0000
Received: (at 68958) by debbugs.gnu.org; 11 Feb 2024 17:55:20 +0000
Received: from localhost ([127.0.0.1]:35533 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1rZE2y-0001uC-6o
for submit <at> debbugs.gnu.org; Sun, 11 Feb 2024 12:55:20 -0500
Received: from relay7-d.mail.gandi.net ([217.70.183.200]:52823)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <juri@HIDDEN>) id 1rZDzG-0001ib-Mo
for 68958 <at> debbugs.gnu.org; Sun, 11 Feb 2024 12:51:31 -0500
Received: by mail.gandi.net (Postfix) with ESMTPSA id F287120005;
Sun, 11 Feb 2024 17:51:06 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
In-Reply-To: <53a9fafc-7b2a-485e-b6c1-df3f372b60e2@HIDDEN> (Dmitry Gutov's
message of "Sun, 11 Feb 2024 05:21:25 +0200")
Organization: LINKOV.NET
References: <m1h6ilgxee.fsf@HIDDEN> <868r3wi57v.fsf@HIDDEN>
<53a9fafc-7b2a-485e-b6c1-df3f372b60e2@HIDDEN>
Date: Sun, 11 Feb 2024 19:37:59 +0200
Message-ID: <86a5o6yk94.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain
X-GND-Sasl: juri@HIDDEN
X-Spam-Score: -0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)
>> I once tried to use 'revert-buffer-function' to restore
>> xref buffers from the desktop, but abandoned the idea.
>> Not because xref.el doesn't set 'revert-buffer-function'.
>> But because it would take too much time to restore
>> the desktop while it will rerun all saved xref buffers.
>> OTOH, saving an xref bookmark makes more sense.
>> And probably your patch will help to implement
>> 'revert-buffer-function' for xref as well.
>
> I don't think bookmark would save the whole buffer contents. Would it?
> Otherwise, re-running the search(es) seems inevitable.
Indeed, saving the buffer contents of transient buffers
either to the bookmark or to the desktop makes no sense.
So re-running the command is inevitable.
But then I can't imagine how would it be possible
to move point to its saved location when initially
a restored buffer is empty before re-running the command.
X-Loop: help-debbugs@HIDDEN
Subject: bug#68958: [PATCH] Support bookmarking Xref results buffers
Resent-From: Dmitry Gutov <dmitry@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 11 Feb 2024 22:47:01 +0000
Resent-Message-ID: <handler.68958.B68958.170769157328553 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 68958
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Juri Linkov <juri@HIDDEN>
Cc: Eshel Yaron <me@HIDDEN>, 68958 <at> debbugs.gnu.org
Received: via spool by 68958-submit <at> debbugs.gnu.org id=B68958.170769157328553
(code B ref 68958); Sun, 11 Feb 2024 22:47:01 +0000
Received: (at 68958) by debbugs.gnu.org; 11 Feb 2024 22:46:13 +0000
Received: from localhost ([127.0.0.1]:55362 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1rZIaT-0007QR-9M
for submit <at> debbugs.gnu.org; Sun, 11 Feb 2024 17:46:13 -0500
Received: from wout5-smtp.messagingengine.com ([64.147.123.21]:59603)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <dmitry@HIDDEN>) id 1rZIaR-0007Q5-Lw
for 68958 <at> debbugs.gnu.org; Sun, 11 Feb 2024 17:46:12 -0500
Received: from compute6.internal (compute6.nyi.internal [10.202.2.47])
by mailout.west.internal (Postfix) with ESMTP id 46BEF3200A88;
Sun, 11 Feb 2024 17:45:49 -0500 (EST)
Received: from mailfrontend1 ([10.202.2.162])
by compute6.internal (MEProxy); Sun, 11 Feb 2024 17:45:49 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc
:cc:content-transfer-encoding:content-type:content-type:date
:date:from:from:in-reply-to:in-reply-to:message-id:mime-version
:references:reply-to:subject:subject:to:to; s=fm2; t=1707691548;
x=1707777948; bh=tpz48uGtWuyZGgQC+0OUFcyc4xdP/pbWcUndh62wXoc=; b=
VWjezlNjN12eB0y+GgvuE/k0/wzvfvyqAj0ecxtWdP9jIBkdePnb+W3HHE0dW9KC
l8/35jLZ8VHmfN0JAl9NxfebbEycVUoDo1lNQG163bM5vM9McuCEDEjRYb6DRswR
QbsG0V0I2LNWXGosy4AgAk9t/oOViqqb+zqABkshXfPxOk53vPQbfhHPikIqWqPE
J5QtIW27utPfOdgZHvu0ZF9VLPftGv/xq7Ka5O+DT3pW5eXX6TWczsU5w7wNzHB+
SP02YTFJZPKQI0Zkf0ykP/TSoJZlGkrLqAiwlmBx+bLspu/gberP+ud8j7a/g7hG
C1Zk6LuWWYsnSuOhLZc6RA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
messagingengine.com; h=cc:cc:content-transfer-encoding
:content-type:content-type:date:date:feedback-id:feedback-id
:from:from:in-reply-to:in-reply-to:message-id:mime-version
:references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy
:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1707691548; x=
1707777948; bh=tpz48uGtWuyZGgQC+0OUFcyc4xdP/pbWcUndh62wXoc=; b=U
QySaOwp4vyW/1njJTMrUk2amYtfYMeGbDUetbBV2p8xk+D+kfxzLuy2Bri2oX+6+
uP7epcuQbbNFW6lIP3jBiPrZ1hek61qConOQIj66iMpxszNGIo9tZ4Kj2pIUyU1p
w/d/Qv4cikWLvXY7izI7KMSUejkex0Sulb1DYfk8zQNy/XUPDLcCbJYHDJxQ2fMS
wCMcUAkUQfZxWNaVsItYFk+ByK7GA6b5aMicNqRtC43Td4ofIXYb961IGgDZ1jEQ
+4oIFCs7CxHevR7ELu5Qwt4TgbjCzcfyYzFZZUmkmHQ0On3fAb/PpuLk+IzxyrwM
HLPhd/c44pY6KnDRWZ+Og==
X-ME-Sender: <xms:HE7JZStuhGbzDa25lXEKXlTyVJ3c0qmMSPbk5sOMbWuvUq4wKKgDQQ>
<xme:HE7JZXem98IWb1XbdKLWNCHdmewiLf83RLHFSVF88v0ta_wz08OC0-T2jVWiiPHUB
SE-iMdYNtE31HwLlz8>
X-ME-Received: <xmr:HE7JZdwiFSI1-FidSbHZBRVO0RL3zbuThc-OzVu83UJzYjj-muxAeWpTjBpVswQZtFQz>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledruddvgddtvdcutefuodetggdotefrodftvf
curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu
uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc
fjughrpefkffggfgfuvfevfhfhjggtgfesthejredttddvjeenucfhrhhomhepffhmihht
rhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrghtth
gvrhhnpeetudeljeegheetgfehgeejkeeuhedvveeikeeufedtvddtveefhfdvveegudej
heenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumh
hithhrhiesghhuthhovhdruggvvh
X-ME-Proxy: <xmx:HE7JZdPrBLBfSRU5XsnE1Fr1Pi7uaNBg8mNdmDTVGuJX9Y_i4vet1w>
<xmx:HE7JZS-_v_pZWN5CoXZtKY-QD1OA1jzkVrxOSX1HbTA1nZs_yu5-SA>
<xmx:HE7JZVU9o4tppk1isnSoNymPqvf2jqFWsjzyq2eZbwl2_fYcjITa6A>
<xmx:HE7JZYl-8PwYHghUNyeNoKbC-AAOs6ryNgvdhL_lZ9VSfet3UJ0_Hg>
Feedback-ID: i0e71465a:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun,
11 Feb 2024 17:45:47 -0500 (EST)
Message-ID: <378d3773-c8d9-4048-ac14-6dee0c2c290d@HIDDEN>
Date: Mon, 12 Feb 2024 00:45:47 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
References: <m1h6ilgxee.fsf@HIDDEN> <868r3wi57v.fsf@HIDDEN>
<53a9fafc-7b2a-485e-b6c1-df3f372b60e2@HIDDEN>
<86a5o6yk94.fsf@HIDDEN>
From: Dmitry Gutov <dmitry@HIDDEN>
In-Reply-To: <86a5o6yk94.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
On 11/02/2024 19:37, Juri Linkov wrote:
>>> I once tried to use 'revert-buffer-function' to restore
>>> xref buffers from the desktop, but abandoned the idea.
>>> Not because xref.el doesn't set 'revert-buffer-function'.
>>> But because it would take too much time to restore
>>> the desktop while it will rerun all saved xref buffers.
>>> OTOH, saving an xref bookmark makes more sense.
>>> And probably your patch will help to implement
>>> 'revert-buffer-function' for xref as well.
>> I don't think bookmark would save the whole buffer contents. Would it?
>> Otherwise, re-running the search(es) seems inevitable.
> Indeed, saving the buffer contents of transient buffers
> either to the bookmark or to the desktop makes no sense.
> So re-running the command is inevitable.
>
> But then I can't imagine how would it be possible
> to move point to its saved location when initially
> a restored buffer is empty before re-running the command.
As long as the search is performed synchronously, first you "revert" the
buffer and then move point. Right?
X-Loop: help-debbugs@HIDDEN
Subject: bug#68958: [PATCH] Support bookmarking Xref results buffers
Resent-From: Dmitry Gutov <dmitry@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 11 Feb 2024 23:12:01 +0000
Resent-Message-ID: <handler.68958.B68958.17076930871184 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 68958
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Eshel Yaron <me@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, 68958 <at> debbugs.gnu.org
Received: via spool by 68958-submit <at> debbugs.gnu.org id=B68958.17076930871184
(code B ref 68958); Sun, 11 Feb 2024 23:12:01 +0000
Received: (at 68958) by debbugs.gnu.org; 11 Feb 2024 23:11:27 +0000
Received: from localhost ([127.0.0.1]:57279 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1rZIys-0000Iy-G3
for submit <at> debbugs.gnu.org; Sun, 11 Feb 2024 18:11:27 -0500
Received: from wout2-smtp.messagingengine.com ([64.147.123.25]:51437)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <dmitry@HIDDEN>) id 1rZIyq-0000Ib-Jk
for 68958 <at> debbugs.gnu.org; Sun, 11 Feb 2024 18:11:25 -0500
Received: from compute7.internal (compute7.nyi.internal [10.202.2.48])
by mailout.west.internal (Postfix) with ESMTP id 30F053200A6B;
Sun, 11 Feb 2024 18:01:31 -0500 (EST)
Received: from mailfrontend1 ([10.202.2.162])
by compute7.internal (MEProxy); Sun, 11 Feb 2024 18:01:31 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc
:cc:content-transfer-encoding:content-type:content-type:date
:date:from:from:in-reply-to:in-reply-to:message-id:mime-version
:references:reply-to:subject:subject:to:to; s=fm2; t=1707692490;
x=1707778890; bh=pa1XM2OHflR58YW5/k1FKmGZFuFylsQExpSfoMP+njQ=; b=
Qc3J1D6JutYIydx0/10LtqTmaN6heqIJuPnwNr/guZENNX3cqxEkhIGM3C0SFoxK
OWt4lsZ2mejUuLhAIAL6iDBLNl/mGXVKwVI032XJxtElWDMuSMc6Ev1Y534a3C9q
ebjJiFwdPYGIkRkKX23YkT+ZA2AtanDdwDIsBJK8AR7bhJYyfQe27XdxxoiWWh2j
Gu7PZWIcIYpIWQA63aK7NCjaDH0rP2MSp3P0WPocJw0425/rxMzKxzzsxLney9aG
3WBVSMyT8912l8AN225xh0zjX+K7C8NJ9ke5qS3HkTjTXA6oiH1aoroiz6LLd1sP
yupkuwi4hv/P8uA4hQcjNA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
messagingengine.com; h=cc:cc:content-transfer-encoding
:content-type:content-type:date:date:feedback-id:feedback-id
:from:from:in-reply-to:in-reply-to:message-id:mime-version
:references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy
:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1707692490; x=
1707778890; bh=pa1XM2OHflR58YW5/k1FKmGZFuFylsQExpSfoMP+njQ=; b=Q
nAKgYEL7HoyaqAG0OlwK138HPKdbv6sfz2BxIkZbrDHVmROmcSPPxBcZ9nMgAvDx
6pKjsQdJ2PCzH4/uEgytkVZ91yYxFVg4+OBLGku9LMYemPTFiK+kW2rR856icmlz
+Nu7fYnjZwYFbdPyzncCozuToxJYM8EQ1jfPt/klLuR2GS5TpWFt6ifRytJnQFVE
lxoEjVXxmb4HYRAkdLvExfgfMEHVoAPLyFTyV4830f59O4zBlwUBW4QbHHPSDxBt
bwtEMGl0cvq1hLvgSmIDANfzo8VlgWob8VU1V3XtrJUUDRIZQStBBZjUmaIf/Nxa
8pgs2yjJ3N1aePLWuYp5A==
X-ME-Sender: <xms:ylHJZVjAwxpziHCNnZ4GAwsMuDqc55DTmTFR9dt46D6fWxrmttc8dA>
<xme:ylHJZaARPi1_gnMJYr9rQO8nYzOvD8qWF_O865-zz9cOR7mijLyEaAgeow0Z0TtvM
PDKiT89F6kzyCoW49c>
X-ME-Received: <xmr:ylHJZVGZI_6BsuldrWoaC3lzpWL18bAUMJL2GL9owhae3M16GjZKcNBtt1HlaYkwTiqN>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledruddvgddtgecutefuodetggdotefrodftvf
curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu
uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc
fjughrpefkffggfgfuvfevfhfhjggtgfesthejredttddvjeenucfhrhhomhepffhmihht
rhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrghtth
gvrhhnpeetudeljeegheetgfehgeejkeeuhedvveeikeeufedtvddtveefhfdvveegudej
heenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumh
hithhrhiesghhuthhovhdruggvvh
X-ME-Proxy: <xmx:ylHJZaR5dgriOOGEQtNRAV6b1fyK1FEm9uw7rErk32drEJ_9fDtt3A>
<xmx:ylHJZSznLn2EYxVVHCyPHWb9YXmWepXv-w4zgNKXskAzhvgqj9QqNQ>
<xmx:ylHJZQ6SIDakmQuNp2MaNHo53MAxzKqD7AQqt4bjWSVbFX5iIAInXg>
<xmx:ylHJZXqV3XpmNIyi8Bl4yaSJRWyFwzRYwjFIEhUVa3GAX7eVF1G8zQ>
Feedback-ID: i0e71465a:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun,
11 Feb 2024 18:01:29 -0500 (EST)
Message-ID: <1bea3fe4-51aa-418b-a55f-f09d0a4c558e@HIDDEN>
Date: Mon, 12 Feb 2024 01:01:28 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
References: <m1h6ilgxee.fsf@HIDDEN> <86le7wzcjj.fsf@HIDDEN>
<0b3f4669-180e-466f-96f3-7eeae994581f@HIDDEN>
<m1cyt35xrj.fsf@HIDDEN>
<b521e786-377c-4834-be68-87a824ae6384@HIDDEN>
<m14jee5341.fsf@HIDDEN>
From: Dmitry Gutov <dmitry@HIDDEN>
In-Reply-To: <m14jee5341.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
On 11/02/2024 19:21, Eshel Yaron wrote:
> Dmitry Gutov <dmitry@HIDDEN> writes:
>
>> On 11/02/2024 08:18, Eshel Yaron wrote:
>>
>>> Again, the name of the bookmark is really not the focus here. We can't
>>> persist the value of xref--fetcher, since it's an anonymous function, so
>>> we get all the info needed to /recreate/ that function to the frontend.
>>> If there's another (simpler?) way to provide this feature, please do tell.
>>
>> All right, that's a good point.
>>
>> Could we really not persist an anonymous function, though? It can be
>> printed and, I suppose, evaluated. At least in theory, whatever links
>> it has to containing lexical contexts, should be possible to "detach"
>> when writing the literal to disk, to be read later.
>
> I'm not sure. It certainly cant' work for arbitrary function objects
> (say, if you create a function with 'make_function' in a module).
We could detect some such functions (e.g. when the value is a subr, and
thus not readable), but we would still support a large varied class of
functions this way.
Also, we'd probably want to limit the size of the printed representation
(FETCHER created by project-find-regexp currently closes over the full
list of files, that's too much to save; it will probably be a good idea
to rewrite it to fetch the list of files anew).
>> The issue with doing this at the level of xref--create-fetcher, is
>> that the addition becomes specific to the Xref searches only (find
>> definitions/references), and the more generic Xref UI infrastructure
>> remains unsupported (such as 'M-x project-find-regexp' or whatever
>> calls to xref-show-xrefs exist in third-party packages) -- so those
>> Xref buffers would remain not bookmark-able, or they will each require
>> specialized code like the one you proposed here.
>
> Yes, but such callers of xref-show-xrefs can implement the same API to
> have the corresponding *xref* buffer bookmark-able. Namely, arrange for
> the fetcher function to populate xref-fetcher-alist with relevant data.
With that, the simple API "patch FETCHER and DISPLAY-ACTION (probably
nil)" would turn into something at least twice (or 3x) as complex.
I'm not quite convinced that being able to bookmark Xref buffers is
worth this cost.
Also note that with such addition the clients would basically pass the
same information twice: they would both create the fetcher, *and* still
have to produce the data with which this fetcher is created, and the
logic to work on it.
This information duplication could be avoided perhaps if we split the
fetcher into a function symbol and arguments (a new optional argument to
xref-show-xrefs and xref--show-defs, I suppose). When the caller is able
to restructure the code to pass a named function as the first arg, the
result should be print-able. But then they'd have to be careful to keep
the arguments "simple" too, like not referencing the buffer object
itself (just its name), etc. That's a fair amount of implicit
requirements...
> Indeed, I plan to work on doing that for project-find-regexp next.
The approach with xref-backend-restore wouldn't work for it because
there is no backend to work with.
> If
> we had a solution that doesn't require any work from third party to
> benefit from this new feature, that'd be even better, of course. But
> since the current API to Xref frontends accepts any fetcher function,
> I'm not sure that's possible...
Perhaps our interpreter wizards could chime in regarding the
roundtrip-ability of anonymous functions.
Whatever is required to make this work, would likely still require less
collective effort than redoing the Xref APIs.
X-Loop: help-debbugs@HIDDEN
Subject: bug#68958: [PATCH] Support bookmarking Xref results buffers
Resent-From: Eshel Yaron <me@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 12 Feb 2024 11:53:01 +0000
Resent-Message-ID: <handler.68958.B68958.170773876914535 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 68958
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Dmitry Gutov <dmitry@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, 68958 <at> debbugs.gnu.org
Received: via spool by 68958-submit <at> debbugs.gnu.org id=B68958.170773876914535
(code B ref 68958); Mon, 12 Feb 2024 11:53:01 +0000
Received: (at 68958) by debbugs.gnu.org; 12 Feb 2024 11:52:49 +0000
Received: from localhost ([127.0.0.1]:51148 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1rZUrh-0003mL-4l
for submit <at> debbugs.gnu.org; Mon, 12 Feb 2024 06:52:49 -0500
Received: from mail.eshelyaron.com ([107.175.124.16]:58136 helo=eshelyaron.com)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <me@HIDDEN>) id 1rZUrf-0003m6-9D
for 68958 <at> debbugs.gnu.org; Mon, 12 Feb 2024 06:52:47 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eshelyaron.com;
s=mail; t=1707738337;
bh=c86sOe/WqVsOwbRqrNPZjmBdEluKtRMZDUJnqhWl49w=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=EAWflWEW5iqKUQUyDzmhooR+HoCzx/1N8zWPC3zJM7JzpTbhyalfmY831lUUAwqVS
ZMaUIW6ASZPciQAx9p0sgZbC7LY7IKKfdv+eaWcngUK/XW4i0cIc8eS2SYUFT0wqPI
osJ9N2DZMtpIKxt6wzN2E90pZUwrDcO/NbUnFggwGz8NVnpLfJPB8ShufwtVQBmopc
fPisqS/CmwBVdnarvo8BIVCJeH80nhtl9xRJwnH8bz8mF7YoWvV3stKilPyQKgy/D0
lzpNjUYXJlxAigbbhRPrmreg39PkQraHSkoZMAKlh+dE9AX8C0UCpj48qC+zVWqeGZ
hRH3XGWtRJv2A==
From: Eshel Yaron <me@HIDDEN>
In-Reply-To: <1bea3fe4-51aa-418b-a55f-f09d0a4c558e@HIDDEN> (Dmitry Gutov's
message of "Mon, 12 Feb 2024 01:01:28 +0200")
References: <m1h6ilgxee.fsf@HIDDEN> <86le7wzcjj.fsf@HIDDEN>
<0b3f4669-180e-466f-96f3-7eeae994581f@HIDDEN>
<m1cyt35xrj.fsf@HIDDEN>
<b521e786-377c-4834-be68-87a824ae6384@HIDDEN>
<m14jee5341.fsf@HIDDEN>
<1bea3fe4-51aa-418b-a55f-f09d0a4c558e@HIDDEN>
Date: Mon, 12 Feb 2024 12:45:35 +0100
Message-ID: <m1jzn9ewio.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.3 (/)
Hi Dmitry,
Dmitry Gutov <dmitry@HIDDEN> writes:
>>> The issue with doing this at the level of xref--create-fetcher, is
>>> that the addition becomes specific to the Xref searches only (find
>>> definitions/references), and the more generic Xref UI infrastructure
>>> remains unsupported (such as 'M-x project-find-regexp' or whatever
>>> calls to xref-show-xrefs exist in third-party packages) -- so those
>>> Xref buffers would remain not bookmark-able, or they will each require
>>> specialized code like the one you proposed here.
>> Yes, but such callers of xref-show-xrefs can implement the same API
>> to
>> have the corresponding *xref* buffer bookmark-able. Namely, arrange for
>> the fetcher function to populate xref-fetcher-alist with relevant data.
>
> With that, the simple API "patch FETCHER and DISPLAY-ACTION (probably
> nil)" would turn into something at least twice (or 3x) as complex.
Well, ISTM that one could also say that the API is as simple as it was:
you pass the same stuff, and get the same result. It's just that,
optionally, you can also do a bit more (set a variable inside FETCHER)
and get a bit more (bookmarking). I agree that redundant complexity is
better avoided, but this is the simplest compatible extension to the API
I came up with to implement this feature.
> I'm not quite convinced that being able to bookmark Xref buffers is
> worth this cost.
Fair enough, it's your call. IMO this is a rather useful capability,
and I don't think it's that important to keep the API maximally simple
if it doesn't facilitate everything we want it to. In other words, as
long as we maintain compatibility, what's wrong with extending the API
to support more features?
> Also note that with such addition the clients would basically pass the
> same information twice: they would both create the fetcher, *and*
> still have to produce the data with which this fetcher is created, and
> the logic to work on it.
Yes. We could drop the pre-prepared fetcher function and keep only the
"ingredients", but that'd break compatibility with existing frontends,
so we're stuck with some duplication here AFAICT.
> This information duplication could be avoided perhaps if we split the
> fetcher into a function symbol and arguments (a new optional argument
> to xref-show-xrefs and xref--show-defs, I suppose). When the caller is
> able to restructure the code to pass a named function as the first
> arg, the result should be print-able. But then they'd have to be
> careful to keep the arguments "simple" too, like not referencing the
> buffer object itself (just its name), etc. That's a fair amount of
> implicit requirements...
>
>> Indeed, I plan to work on doing that for project-find-regexp next.
>
> The approach with xref-backend-restore wouldn't work for it because
> there is no backend to work with.
My thinking was that we can add an appropriate backend, and perhaps
adapt project-find-regexp to use the new xref-make-fetcher instead of
concocting the fetcher function itself. But I didn't try it yet so
maybe I'm missing some involved challenges.
Best,
Eshel
X-Loop: help-debbugs@HIDDEN
Subject: bug#68958: [PATCH] Support bookmarking Xref results buffers
Resent-From: Juri Linkov <juri@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 12 Feb 2024 18:41:02 +0000
Resent-Message-ID: <handler.68958.B68958.17077632222753 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 68958
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Dmitry Gutov <dmitry@HIDDEN>
Cc: Eshel Yaron <me@HIDDEN>, 68958 <at> debbugs.gnu.org
Received: via spool by 68958-submit <at> debbugs.gnu.org id=B68958.17077632222753
(code B ref 68958); Mon, 12 Feb 2024 18:41:02 +0000
Received: (at 68958) by debbugs.gnu.org; 12 Feb 2024 18:40:22 +0000
Received: from localhost ([127.0.0.1]:48660 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1rZbE5-0000iG-JR
for submit <at> debbugs.gnu.org; Mon, 12 Feb 2024 13:40:22 -0500
Received: from relay5-d.mail.gandi.net ([2001:4b98:dc4:8::225]:57991)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <juri@HIDDEN>) id 1rZb6p-0000AO-Lj
for 68958 <at> debbugs.gnu.org; Mon, 12 Feb 2024 13:32:52 -0500
Received: by mail.gandi.net (Postfix) with ESMTPSA id CC2881C0003;
Mon, 12 Feb 2024 18:32:26 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
In-Reply-To: <378d3773-c8d9-4048-ac14-6dee0c2c290d@HIDDEN> (Dmitry Gutov's
message of "Mon, 12 Feb 2024 00:45:47 +0200")
Organization: LINKOV.NET
References: <m1h6ilgxee.fsf@HIDDEN> <868r3wi57v.fsf@HIDDEN>
<53a9fafc-7b2a-485e-b6c1-df3f372b60e2@HIDDEN>
<86a5o6yk94.fsf@HIDDEN>
<378d3773-c8d9-4048-ac14-6dee0c2c290d@HIDDEN>
Date: Mon, 12 Feb 2024 20:31:20 +0200
Message-ID: <86eddhwn47.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain
X-GND-Sasl: juri@HIDDEN
X-Spam-Score: -0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)
>>>> I once tried to use 'revert-buffer-function' to restore
>>>> xref buffers from the desktop, but abandoned the idea.
>>>> Not because xref.el doesn't set 'revert-buffer-function'.
>>>> But because it would take too much time to restore
>>>> the desktop while it will rerun all saved xref buffers.
>>>> OTOH, saving an xref bookmark makes more sense.
>>>> And probably your patch will help to implement
>>>> 'revert-buffer-function' for xref as well.
>>> I don't think bookmark would save the whole buffer contents. Would it?
>>> Otherwise, re-running the search(es) seems inevitable.
>> Indeed, saving the buffer contents of transient buffers
>> either to the bookmark or to the desktop makes no sense.
>> So re-running the command is inevitable.
>> But then I can't imagine how would it be possible
>> to move point to its saved location when initially
>> a restored buffer is empty before re-running the command.
>
> As long as the search is performed synchronously, first you "revert" the
> buffer and then move point. Right?
Sorry, I forgot that xref is not asynchronous as rgrep.
But this is not a problem: most of the time xref delay
is negligible. Still would not want to run it while
restoring the desktop. But from a bookmark is fine.
X-Loop: help-debbugs@HIDDEN
Subject: bug#68958: [PATCH] Support bookmarking Xref results buffers
Resent-From: Dmitry Gutov <dmitry@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 12 Feb 2024 18:42:01 +0000
Resent-Message-ID: <handler.68958.B68958.17077632783049 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 68958
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Juri Linkov <juri@HIDDEN>
Cc: Eshel Yaron <me@HIDDEN>, 68958 <at> debbugs.gnu.org
Received: via spool by 68958-submit <at> debbugs.gnu.org id=B68958.17077632783049
(code B ref 68958); Mon, 12 Feb 2024 18:42:01 +0000
Received: (at 68958) by debbugs.gnu.org; 12 Feb 2024 18:41:18 +0000
Received: from localhost ([127.0.0.1]:48733 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1rZbEz-0000n4-Q8
for submit <at> debbugs.gnu.org; Mon, 12 Feb 2024 13:41:18 -0500
Received: from out3-smtp.messagingengine.com ([66.111.4.27]:57461)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <dmitry@HIDDEN>) id 1rZbEw-0000mP-Vh
for 68958 <at> debbugs.gnu.org; Mon, 12 Feb 2024 13:41:16 -0500
Received: from compute2.internal (compute2.nyi.internal [10.202.2.46])
by mailout.nyi.internal (Postfix) with ESMTP id 707355C00B7;
Mon, 12 Feb 2024 13:40:52 -0500 (EST)
Received: from mailfrontend1 ([10.202.2.162])
by compute2.internal (MEProxy); Mon, 12 Feb 2024 13:40:52 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc
:cc:content-transfer-encoding:content-type:content-type:date
:date:from:from:in-reply-to:in-reply-to:message-id:mime-version
:references:reply-to:subject:subject:to:to; s=fm2; t=1707763252;
x=1707849652; bh=aE6bdE0hjCXbFsMKiNIZF8P3NhUJOUuh6/vbB8+bXto=; b=
SnKOmj5LtUFszG6gFP1VTdsz/xMsNRp6LMth82/bft9AcuFCL0fhw9CXMKtGHPdu
Z3Yczitg+lLM+xjdJW/BDEjuH1tA2LHEcGb0lhUgTMUpgZ4fj40RnQoVRV4j8/lm
j6iek398Ii9iNWVb/2pjZ5+SyyMI0P5V1K/RupgH3b669NYc8o4yAT+H7TQN6fIJ
XGzW4Ml0YljOnCQVSuApd65pWRo+flcwZWiHruquPi/XhaWUyBC501vrtbqZuTm8
o3bJKljmUaaibCGBDVlf5wjnQaia+lf5/iAtk+UQNpJPxc/7O6vhEeBByzzDCvYf
xyobz38NMYVCAtTlirpCkg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
messagingengine.com; h=cc:cc:content-transfer-encoding
:content-type:content-type:date:date:feedback-id:feedback-id
:from:from:in-reply-to:in-reply-to:message-id:mime-version
:references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy
:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1707763252; x=
1707849652; bh=aE6bdE0hjCXbFsMKiNIZF8P3NhUJOUuh6/vbB8+bXto=; b=N
NByPckF4wHneU1EDDTrMRn2/H3ib3S7ohB3pARKUv/lH2nD6Nv+f0ccg9xiOd18c
+VHuO1rbwCA4UNt4KTNCdJEKLUVDuWophigvzUAMmxC+npOWW5u3MuCZdF/CQzZn
dNG/i4GQkqaA8Vh1+bb8pPeKj76Ba8rRq24LqKddsigQ4de/uG+J16I+qsUSsbkV
fbOEa+wE3sP0RjvQmZ5wRRAU81VBlEy3eQ+xOQkiXx5Cp6IjPZO8KNp2NA98ziHs
8+p+6Hs24T5erBduceMqjz1X/WiyAqT7g9V4QJqS5Asi2s2c5vP/uaQJaZ7nCg17
k8Sd2fbsMLsONCHeavOmw==
X-ME-Sender: <xms:NGbKZfg0HEauNHriU4asDLrDDoi6RjAKhvt8C3EfN0oB1huw15wLbw>
<xme:NGbKZcB5L17FeF6wjGkdIzzKZTy5i4EwHktblvj45KfvpGrKP2kSnPvPzP9f_eUGr
qg7EBZNVz-ZHi1Kef8>
X-ME-Received: <xmr:NGbKZfGu-XXU2wqKSL_Wt-tQj8d_9LeO4_ZRJYzkmkgOg2zqMUD9l-Nz-7FCTBLOL7T5>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrudefgdduudegucetufdoteggodetrfdotf
fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne
cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtvdejnecuhfhrohhmpeffmhhi
thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth
htvghrnhepteduleejgeehtefgheegjeekueehvdevieekueeftddvtdevfefhvdevgedu
jeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug
hmihhtrhihsehguhhtohhvrdguvghv
X-ME-Proxy: <xmx:NGbKZcRuixfkuq6Ln-GeuaCd3dln_aDZ7bHjiwkHJUckX1Dub4Hl3w>
<xmx:NGbKZcwF1pwoETbcdgUxWvoYgUfccex8e-N6eONDmFM0uk_Qk-snlw>
<xmx:NGbKZS5cTNHv2lCNWlmxmEuLgDF7UMi6bEQ1exct1vGftHKoNvJQIg>
<xmx:NGbKZZoOcHyGQlyXBKHh7IofekAnAIJQbBSrklV-Ax64Pr7EFvzcQA>
Feedback-ID: i0e71465a:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon,
12 Feb 2024 13:40:51 -0500 (EST)
Message-ID: <5f75e9d3-c2e4-4f97-8cff-71032234c880@HIDDEN>
Date: Mon, 12 Feb 2024 20:40:49 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
References: <m1h6ilgxee.fsf@HIDDEN> <868r3wi57v.fsf@HIDDEN>
<53a9fafc-7b2a-485e-b6c1-df3f372b60e2@HIDDEN>
<86a5o6yk94.fsf@HIDDEN>
<378d3773-c8d9-4048-ac14-6dee0c2c290d@HIDDEN>
<86eddhwn47.fsf@HIDDEN>
From: Dmitry Gutov <dmitry@HIDDEN>
In-Reply-To: <86eddhwn47.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
On 12/02/2024 20:31, Juri Linkov wrote:
>>>>> I once tried to use 'revert-buffer-function' to restore
>>>>> xref buffers from the desktop, but abandoned the idea.
>>>>> Not because xref.el doesn't set 'revert-buffer-function'.
>>>>> But because it would take too much time to restore
>>>>> the desktop while it will rerun all saved xref buffers.
>>>>> OTOH, saving an xref bookmark makes more sense.
>>>>> And probably your patch will help to implement
>>>>> 'revert-buffer-function' for xref as well.
>>>> I don't think bookmark would save the whole buffer contents. Would it?
>>>> Otherwise, re-running the search(es) seems inevitable.
>>> Indeed, saving the buffer contents of transient buffers
>>> either to the bookmark or to the desktop makes no sense.
>>> So re-running the command is inevitable.
>>> But then I can't imagine how would it be possible
>>> to move point to its saved location when initially
>>> a restored buffer is empty before re-running the command.
>> As long as the search is performed synchronously, first you "revert" the
>> buffer and then move point. Right?
> Sorry, I forgot that xref is not asynchronous as rgrep.
> But this is not a problem: most of the time xref delay
> is negligible. Still would not want to run it while
> restoring the desktop. But from a bookmark is fine.
Desktop could use some deferring strategy - e.g. delaying the search
until the buffer is shown.
Anyway, that's secondary to being able to restore such a buffer at all.
X-Loop: help-debbugs@HIDDEN
Subject: bug#68958: [PATCH] Support bookmarking Xref results buffers
Resent-From: Dmitry Gutov <dmitry@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 13 Feb 2024 03:19:02 +0000
Resent-Message-ID: <handler.68958.B68958.170779433523383 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 68958
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Eshel Yaron <me@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, 68958 <at> debbugs.gnu.org
Received: via spool by 68958-submit <at> debbugs.gnu.org id=B68958.170779433523383
(code B ref 68958); Tue, 13 Feb 2024 03:19:02 +0000
Received: (at 68958) by debbugs.gnu.org; 13 Feb 2024 03:18:55 +0000
Received: from localhost ([127.0.0.1]:38990 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1rZjJu-000655-O3
for submit <at> debbugs.gnu.org; Mon, 12 Feb 2024 22:18:55 -0500
Received: from out2-smtp.messagingengine.com ([66.111.4.26]:32935)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <dmitry@HIDDEN>) id 1rZjJt-00064j-1U
for 68958 <at> debbugs.gnu.org; Mon, 12 Feb 2024 22:18:53 -0500
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45])
by mailout.nyi.internal (Postfix) with ESMTP id A78795C0109;
Mon, 12 Feb 2024 22:18:30 -0500 (EST)
Received: from mailfrontend1 ([10.202.2.162])
by compute5.internal (MEProxy); Mon, 12 Feb 2024 22:18:30 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc
:cc:content-transfer-encoding:content-type:content-type:date
:date:from:from:in-reply-to:in-reply-to:message-id:mime-version
:references:reply-to:subject:subject:to:to; s=fm2; t=1707794310;
x=1707880710; bh=44/cVQPgC06FYU+giG1E/r4PGbUEq5Hpokk+JMHvXG4=; b=
j4r+XPyvb5QSdYUCDeWFGgZEw8LVQLiWWxXZRvzZD1Pd8xJwkPCnU+fFRx7f59/4
dnGDWM7OJi4JBPv17zH1S98/qZPzy24/wXGfEAU+qlGCOLrslovbDfGacotTfpfU
Clki94Gu0Qo5yertHKut07XSJXWQb//xWsqIjTAAomwZnv8AbT49moYqQt8W8k0g
gd/lDD3dccFSmgNvEUmHWeNwsEOn9uOgaIvokqbSdJg1pHIBE3La1EDg2rlDMVBV
UrC6+shfLIikH5lEaiZbqMgfUzzXVNUpb7G9AuIZtiMMRFLPJZ6za0Osy3ZVjtKG
SP6VxgoGf+4COb4ANYmbXg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
messagingengine.com; h=cc:cc:content-transfer-encoding
:content-type:content-type:date:date:feedback-id:feedback-id
:from:from:in-reply-to:in-reply-to:message-id:mime-version
:references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy
:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1707794310; x=
1707880710; bh=44/cVQPgC06FYU+giG1E/r4PGbUEq5Hpokk+JMHvXG4=; b=L
p5CZALirlhBz3izwMXzhOIwveKPYcV3l+00tykuedjT/U4wtDZI83BoU4oTCW4KG
IRow6dRwyAQTmItUJ0T09H3kDlzEOF3r4mnJ5XbKgPKJV+nD5AcMQhfHtuvZiRUd
299zvi8k7tLB2HKFuZ2nE4j9W0thMND4k6dtcMnF+2h2yE8c33cA+QhuBeW2npoZ
rZFgSzLqSK7mfgmkRZknCAdaAuIsSVNAXyLzLDMFWQfKQVn+9YCkj6nKSk61z/57
pfMD9olHyIDAM+ykSgUHFxSfHg10KEpkyvtOey1iDxfc7A6Ox7mUevttjVaM797F
B+l2JEemiEzzvOnQsNHgw==
X-ME-Sender: <xms:ht_KZatsyHN9XqbW5Gyv1zjp-qdpPdw4ao6SB-kpTaOFBMXSuoLcYg>
<xme:ht_KZfcCkh0dNA2eEY8eTaqgAhzBd9_IckXyKZGTIGl1C1AJ56KYtEGa-A-kBIbe3
Vno-OQWXAIct3wkWnE>
X-ME-Received: <xmr:ht_KZVyF6aqhZWvDa_ux4B6BxZEclLk5BCcOfzon6wf_93wm4Ihv2xIB2jZ9ExkS9xCD>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrudeggdehlecutefuodetggdotefrodftvf
curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu
uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc
fjughrpefkffggfgfuvfevfhfhjggtgfesthejredttddvjeenucfhrhhomhepffhmihht
rhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrghtth
gvrhhnpeetudeljeegheetgfehgeejkeeuhedvveeikeeufedtvddtveefhfdvveegudej
heenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumh
hithhrhiesghhuthhovhdruggvvh
X-ME-Proxy: <xmx:ht_KZVPc8ZBaOLM4uMyAVSkZHunkBfsLtUFmYuyV_BRlPxRVqt5Ujg>
<xmx:ht_KZa8ltVWZgtLp12Wz31VFhF7emryuP3MIVGfIMWehdFsONtExqw>
<xmx:ht_KZdXhNj6T_8XiTFhSTlR8bLUN1AIM4nNt50N8Y3Us3Owf81zrng>
<xmx:ht_KZQn_WmdJ8jg1Q0FN4tcnRF5gmLQnWnlIqkeK4LDoWEJAGjLmzg>
Feedback-ID: i0e71465a:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon,
12 Feb 2024 22:18:29 -0500 (EST)
Message-ID: <653af486-3b3b-4270-8385-ee3af6639eb5@HIDDEN>
Date: Tue, 13 Feb 2024 05:18:28 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
References: <m1h6ilgxee.fsf@HIDDEN> <86le7wzcjj.fsf@HIDDEN>
<0b3f4669-180e-466f-96f3-7eeae994581f@HIDDEN>
<m1cyt35xrj.fsf@HIDDEN>
<b521e786-377c-4834-be68-87a824ae6384@HIDDEN>
<m14jee5341.fsf@HIDDEN>
<1bea3fe4-51aa-418b-a55f-f09d0a4c558e@HIDDEN>
<m1jzn9ewio.fsf@HIDDEN>
From: Dmitry Gutov <dmitry@HIDDEN>
In-Reply-To: <m1jzn9ewio.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
On 12/02/2024 13:45, Eshel Yaron wrote:
>> With that, the simple API "patch FETCHER and DISPLAY-ACTION (probably
>> nil)" would turn into something at least twice (or 3x) as complex.
>
> Well, ISTM that one could also say that the API is as simple as it was:
> you pass the same stuff, and get the same result. It's just that,
> optionally, you can also do a bit more (set a variable inside FETCHER)
> and get a bit more (bookmarking).
A fair amount more: to fill out an alist, and have a new generic
function implemented.
> I agree that redundant complexity is
> better avoided, but this is the simplest compatible extension to the API
> I came up with to implement this feature.
If we're going to recommend the callers use the new capability, I'd
rather they didn't have to be redundant every time.
>> I'm not quite convinced that being able to bookmark Xref buffers is
>> worth this cost.
>
> Fair enough, it's your call. IMO this is a rather useful capability,
> and I don't think it's that important to keep the API maximally simple
> if it doesn't facilitate everything we want it to. In other words, as
> long as we maintain compatibility, what's wrong with extending the API
> to support more features?
A more concise yet backward-compatible approach could also look like the
below.
Though I'm not sure whether the fetcher should reach
xref-show-xrefs-function intact (simpler code, but a breakage in the
interface, which could be mended with catching
wrong-number-of-arguments), or like in this example, both the original
fetcher and the arguments should be passed through alist.
Otherwise, the requirements on the arguments are the same (fetcher --
named function, args -- printability).
Also, I'm not sure how we're supposed to guarantee that
xref--original-buffer is live. Is that for use with desktop-mode only?
And it seems like as soon as the buffer has some new changes, the
bookmark is likely to become invalid (the same value of point will point
to a different identifier).
Anyway, regarding that partial patch:
diff --git a/lisp/progmodes/xref.el b/lisp/progmodes/xref.el
index 717b837a2e5..cfdb9cd72de 100644
--- a/lisp/progmodes/xref.el
+++ b/lisp/progmodes/xref.el
@@ -1476,13 +1476,13 @@ xref--read-identifier-history
(defvar xref--read-pattern-history nil)
;;;###autoload
-(defun xref-show-xrefs (fetcher display-action)
+(defun xref-show-xrefs (fetcher display-action &optional args)
"Display some Xref values produced by FETCHER using DISPLAY-ACTION.
The meanings of both arguments are the same as documented in
`xref-show-xrefs-function'."
- (xref--show-xrefs fetcher display-action))
+ (xref--show-xrefs fetcher display-action args))
-(defun xref--show-xrefs (fetcher display-action &optional
_always-show-list)
+(defun xref--show-xrefs (fetcher display-action &optional
_always-show-list args)
(unless (functionp fetcher)
;; Old convention.
(let ((xrefs fetcher))
@@ -1494,12 +1494,16 @@ xref--show-xrefs
xrefs
(setq xrefs 'called-already)))))))
(let ((cb (current-buffer))
- (pt (point)))
- (prog1
+ (pt (point))
+ (orig-fetcher fetcher))
+ (when args (setq fetcher (lambda () (apply fetcher args))))
+ (prog1
(funcall xref-show-xrefs-function fetcher
`((window . ,(selected-window))
(display-action . ,display-action)
- (auto-jump . ,xref-auto-jump-to-first-xref)))
+ (auto-jump . ,xref-auto-jump-to-first-xref)
+ (orig-fetcher . ,orig-fetcher)
+ (fetcher-args . ,args)))
(xref--push-markers cb pt))))
(defun xref--show-defs (xrefs display-action)
X-Loop: help-debbugs@HIDDEN
Subject: bug#68958: [PATCH] Support bookmarking Xref results buffers
Resent-From: Eshel Yaron <me@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 13 Feb 2024 07:12:01 +0000
Resent-Message-ID: <handler.68958.B68958.170780827317659 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 68958
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Dmitry Gutov <dmitry@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, 68958 <at> debbugs.gnu.org
Received: via spool by 68958-submit <at> debbugs.gnu.org id=B68958.170780827317659
(code B ref 68958); Tue, 13 Feb 2024 07:12:01 +0000
Received: (at 68958) by debbugs.gnu.org; 13 Feb 2024 07:11:13 +0000
Received: from localhost ([127.0.0.1]:40879 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1rZmwi-0004aj-Kl
for submit <at> debbugs.gnu.org; Tue, 13 Feb 2024 02:11:13 -0500
Received: from mail.eshelyaron.com ([107.175.124.16]:58374 helo=eshelyaron.com)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <me@HIDDEN>) id 1rZmwg-0004ac-Td
for 68958 <at> debbugs.gnu.org; Tue, 13 Feb 2024 02:11:11 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eshelyaron.com;
s=mail; t=1707808253;
bh=PdP7Gao8mMFezw08b+983okY/G5yJL/rjNzx7tMVrsc=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=sJl6ll26W/0FhEdXCz0O5LDdjke4dwHZH2SH2z5DEhpzOnJkZGssyv3W8VcKgM2YD
CJoLBIUDDaBNiGkJMpnie/608ME/cu/WiXFrWcd7SgUB5MMkp++yof2hmwdDyhM9pg
wrC7BLngEV6Dvxzi4ecp9kdEcgjLsmsn3Sj7kshdoBcxmFYCR9b90n3goJcStVkcnp
U4lJFXWPhpTaz8IkRX5on6/9ec17377HZCHxPAZqBxD07bG3hOdMJ/2TuViaewPOKo
T0xXA/Ubn18k80gNITxtB6ZwI7ru2HFroJeI9+nPHTK1sekXxFCZa3bxsGVWR58VBc
dTofiXls1Atlw==
From: Eshel Yaron <me@HIDDEN>
In-Reply-To: <653af486-3b3b-4270-8385-ee3af6639eb5@HIDDEN> (Dmitry Gutov's
message of "Tue, 13 Feb 2024 05:18:28 +0200")
References: <m1h6ilgxee.fsf@HIDDEN> <86le7wzcjj.fsf@HIDDEN>
<0b3f4669-180e-466f-96f3-7eeae994581f@HIDDEN>
<m1cyt35xrj.fsf@HIDDEN>
<b521e786-377c-4834-be68-87a824ae6384@HIDDEN>
<m14jee5341.fsf@HIDDEN>
<1bea3fe4-51aa-418b-a55f-f09d0a4c558e@HIDDEN>
<m1jzn9ewio.fsf@HIDDEN>
<653af486-3b3b-4270-8385-ee3af6639eb5@HIDDEN>
Date: Tue, 13 Feb 2024 08:10:50 +0100
Message-ID: <m18r3ou9dx.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.3 (/)
Dmitry Gutov <dmitry@HIDDEN> writes:
> On 12/02/2024 13:45, Eshel Yaron wrote:
>
>> I agree that redundant complexity is better avoided, but this is the
>> simplest compatible extension to the API I came up with to implement
>> this feature.
>
> If we're going to recommend the callers use the new capability, I'd
> rather they didn't have to be redundant every time.
Often callers can use xref-make-fetcher to make the fetcher function,
and that takes care of the redundant work for them. That's was I did
for project-find-regexp and friends in my working branch, works well :)
[ BTW, while at it, I noticed that the docstring for
project-or-external-find-regexp mentions a prefix argument, but the
function doesn't actually handle one. ]
>>> I'm not quite convinced that being able to bookmark Xref buffers is
>>> worth this cost.
>> Fair enough, it's your call. IMO this is a rather useful
>> capability,
>> and I don't think it's that important to keep the API maximally simple
>> if it doesn't facilitate everything we want it to. In other words, as
>> long as we maintain compatibility, what's wrong with extending the API
>> to support more features?
>
> A more concise yet backward-compatible approach could also look like
> the below.
>
> Though I'm not sure whether the fetcher should reach
> xref-show-xrefs-function intact (simpler code, but a breakage in the
> interface, which could be mended with catching
> wrong-number-of-arguments), or like in this example, both the original
> fetcher and the arguments should be passed through alist.
>
> Otherwise, the requirements on the arguments are the same (fetcher --
> named function, args -- printability).
That might work, although it seems rather difficult to explain such
requirements, and it's difficult for callers to ensure or even check
whether they're kept (how do you know if your argument is too big
without printing it in advance?)
Furthermore, IIUC, what you get is an opaque function and argument list,
and the frontend cannot reason about these, it can only apply the
function to these arguments to get a list of xrefs. In contrast,
xref-fetcher-alist provides clear (documented) semantics. We use it for
bookmarking first and foremost, but the frontend can legitimately use it
for other stuff too, like showing some info in the mode line.
> Also, I'm not sure how we're supposed to guarantee that
> xref--original-buffer is live.
In my patch, we don't guarantee that (see xref-bookmark-make-record).
And that's fine, it's a best effort to give the backend all the context
it might need. If there's no original buffer, we just don't save and
restore that bit of context. The backend can handle a nil CONTEXT
argument in xref-backend-restore however it sees fit. By default, it
does nothing.
> Is that for use with desktop-mode only?
What do you mean? To be clear, this is unrelated to desktop-mode, or at
least I didn't design/implement any of this with desktop-mode in mind.
> And it seems like as soon as the buffer has some new changes, the
> bookmark is likely to become invalid (the same value of point will
> point to a different identifier).
We don't keep the value of point as such, we use the standard bookmark
facilities to save some context around point so we can relocate to the
right place if something changes. If we can't find that context when
restoring the bookmark, point is just left at the beginning of the
*xref* buffer. That's also fine. Does that make sense?
X-Loop: help-debbugs@HIDDEN
Subject: bug#68958: [PATCH] Support bookmarking Xref results buffers
Resent-From: Juri Linkov <juri@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 14 Feb 2024 07:20:02 +0000
Resent-Message-ID: <handler.68958.B68958.170789518721150 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 68958
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Eshel Yaron <me@HIDDEN>
Cc: Dmitry Gutov <dmitry@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, 68958 <at> debbugs.gnu.org
Received: via spool by 68958-submit <at> debbugs.gnu.org id=B68958.170789518721150
(code B ref 68958); Wed, 14 Feb 2024 07:20:02 +0000
Received: (at 68958) by debbugs.gnu.org; 14 Feb 2024 07:19:47 +0000
Received: from localhost ([127.0.0.1]:49943 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1ra9YY-0005V4-Q7
for submit <at> debbugs.gnu.org; Wed, 14 Feb 2024 02:19:47 -0500
Received: from relay5-d.mail.gandi.net ([217.70.183.197]:42933)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <juri@HIDDEN>) id 1ra9YW-0005Uk-UC
for 68958 <at> debbugs.gnu.org; Wed, 14 Feb 2024 02:19:45 -0500
Received: by mail.gandi.net (Postfix) with ESMTPSA id 0F9CC1C0002;
Wed, 14 Feb 2024 07:18:58 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
In-Reply-To: <m18r3ou9dx.fsf@HIDDEN> (Eshel Yaron via's message of
"Tue, 13 Feb 2024 08:10:50 +0100")
Organization: LINKOV.NET
References: <m1h6ilgxee.fsf@HIDDEN> <86le7wzcjj.fsf@HIDDEN>
<0b3f4669-180e-466f-96f3-7eeae994581f@HIDDEN>
<m1cyt35xrj.fsf@HIDDEN>
<b521e786-377c-4834-be68-87a824ae6384@HIDDEN>
<m14jee5341.fsf@HIDDEN>
<1bea3fe4-51aa-418b-a55f-f09d0a4c558e@HIDDEN>
<m1jzn9ewio.fsf@HIDDEN>
<653af486-3b3b-4270-8385-ee3af6639eb5@HIDDEN>
<m18r3ou9dx.fsf@HIDDEN>
Date: Wed, 14 Feb 2024 09:14:17 +0200
Message-ID: <86ttmbqzzq.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain
X-GND-Sasl: juri@HIDDEN
X-Spam-Score: -2.6 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.6 (---)
>> Is that for use with desktop-mode only?
>
> What do you mean? To be clear, this is unrelated to desktop-mode, or at
> least I didn't design/implement any of this with desktop-mode in mind.
Desktop-mode is from the parallel discussion that I started to consider
other beneficial outcomes of applying your patch. It will also allow
to replace xref-revert-buffer with revert-buffer-function: currently
xref-revert-buffer uses xref--fetcher, but with revert-buffer-function
could use xref-fetcher-alist.
X-Loop: help-debbugs@HIDDEN
Subject: bug#68958: [PATCH] Support bookmarking Xref results buffers
Resent-From: Juri Linkov <juri@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 15 Feb 2024 08:56:02 +0000
Resent-Message-ID: <handler.68958.B68958.17079873524829 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 68958
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Dmitry Gutov <dmitry@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, Eshel Yaron <me@HIDDEN>, 68958 <at> debbugs.gnu.org
Received: via spool by 68958-submit <at> debbugs.gnu.org id=B68958.17079873524829
(code B ref 68958); Thu, 15 Feb 2024 08:56:02 +0000
Received: (at 68958) by debbugs.gnu.org; 15 Feb 2024 08:55:52 +0000
Received: from localhost ([127.0.0.1]:54095 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1raXX5-0001Fp-QS
for submit <at> debbugs.gnu.org; Thu, 15 Feb 2024 03:55:52 -0500
Received: from relay8-d.mail.gandi.net ([217.70.183.201]:40215)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <juri@HIDDEN>) id 1raXX4-0001Fb-2w
for 68958 <at> debbugs.gnu.org; Thu, 15 Feb 2024 03:55:50 -0500
Received: by mail.gandi.net (Postfix) with ESMTPSA id E9D641BF205;
Thu, 15 Feb 2024 08:55:23 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
In-Reply-To: <1bea3fe4-51aa-418b-a55f-f09d0a4c558e@HIDDEN> (Dmitry Gutov's
message of "Mon, 12 Feb 2024 01:01:28 +0200")
Organization: LINKOV.NET
References: <m1h6ilgxee.fsf@HIDDEN> <86le7wzcjj.fsf@HIDDEN>
<0b3f4669-180e-466f-96f3-7eeae994581f@HIDDEN>
<m1cyt35xrj.fsf@HIDDEN>
<b521e786-377c-4834-be68-87a824ae6384@HIDDEN>
<m14jee5341.fsf@HIDDEN>
<1bea3fe4-51aa-418b-a55f-f09d0a4c558e@HIDDEN>
Date: Thu, 15 Feb 2024 09:58:19 +0200
Message-ID: <86il2qxg5c.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain
X-GND-Sasl: juri@HIDDEN
X-Spam-Score: -2.6 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.6 (---)
> Also, we'd probably want to limit the size of the printed representation
> (FETCHER created by project-find-regexp currently closes over the full list
> of files, that's too much to save; it will probably be a good idea to
> rewrite it to fetch the list of files anew).
Indeed, I confirm the problem: reverting an xref buffer with 'g'
can't find matches in a new file added after the first run.
Doesn't this hint that both a bookmark and a revert function
should store more high-level arguments? For example, for
'project-find-regexp' it should be sufficient to store
its argument 'regexp' together with 'default-directory'
to reconstruct the previous xref buffer contents.
Then it could store these arguments in a buffer-local variable
that could be used to create a bookmark.
PS: With C-u 'project-find-regexp' reads more arguments
in the body, but such reading should be moved to the
interactive form anyway like 'rgrep' does.
X-Loop: help-debbugs@HIDDEN
Subject: bug#68958: [PATCH] Support bookmarking Xref results buffers
Resent-From: Eshel Yaron <me@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 15 Feb 2024 09:29:01 +0000
Resent-Message-ID: <handler.68958.B68958.17079893078212 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 68958
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Juri Linkov <juri@HIDDEN>
Cc: Dmitry Gutov <dmitry@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, 68958 <at> debbugs.gnu.org
Received: via spool by 68958-submit <at> debbugs.gnu.org id=B68958.17079893078212
(code B ref 68958); Thu, 15 Feb 2024 09:29:01 +0000
Received: (at 68958) by debbugs.gnu.org; 15 Feb 2024 09:28:27 +0000
Received: from localhost ([127.0.0.1]:54104 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1raY2c-00028N-CE
for submit <at> debbugs.gnu.org; Thu, 15 Feb 2024 04:28:27 -0500
Received: from mail.eshelyaron.com ([107.175.124.16]:48514 helo=eshelyaron.com)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <me@HIDDEN>) id 1raY2a-00028D-AL
for 68958 <at> debbugs.gnu.org; Thu, 15 Feb 2024 04:28:25 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eshelyaron.com;
s=mail; t=1707989284;
bh=oK7r/K+7kP7htLA8Pi9M1GIhmYo47HY8RwIh2GNnI5U=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=vUkMQfPEfwsaDdvyUMZtelbqc7F1INO2d39ldo85mwRqcrM+jsZuuLoSCrmK96HjQ
kpOgNPXoNTjCLLnQwxN1KpK2VPoyyQJcJx16Kqfm6CCHT7GZlVIyqzgrrgUOaDjALO
2xQeF5q2fJEZsNwgJzMcepBllBxceOHpirXcs87h4+oMOandXV4EA+oKy/eatgRJF1
atRUtrWy8c/D/MLCpGKr+Cwmp5zbLhI54FydGmT0t86iL9yENGpW3xK+oboeC8FRqm
9h2LeZ112XSbCmA4wZWZkLULBOEXLadyur2hViFZxnRwcch+Ulx85PW3TLlrs65F7V
wSB0W3z53gGnQ==
From: Eshel Yaron <me@HIDDEN>
In-Reply-To: <86il2qxg5c.fsf@HIDDEN> (Juri Linkov's message of "Thu,
15 Feb 2024 09:58:19 +0200")
References: <m1h6ilgxee.fsf@HIDDEN> <86le7wzcjj.fsf@HIDDEN>
<0b3f4669-180e-466f-96f3-7eeae994581f@HIDDEN>
<m1cyt35xrj.fsf@HIDDEN>
<b521e786-377c-4834-be68-87a824ae6384@HIDDEN>
<m14jee5341.fsf@HIDDEN>
<1bea3fe4-51aa-418b-a55f-f09d0a4c558e@HIDDEN>
<86il2qxg5c.fsf@HIDDEN>
Date: Thu, 15 Feb 2024 10:28:02 +0100
Message-ID: <m1frxum5zx.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-Spam-Score: -1.9 (-)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.9 (--)
--=-=-=
Content-Type: text/plain
Hi Juri,
Juri Linkov <juri@HIDDEN> writes:
>> Also, we'd probably want to limit the size of the printed representation
>> (FETCHER created by project-find-regexp currently closes over the full list
>> of files, that's too much to save; it will probably be a good idea to
>> rewrite it to fetch the list of files anew).
>
> Indeed, I confirm the problem: reverting an xref buffer with 'g'
> can't find matches in a new file added after the first run.
>
> Doesn't this hint that both a bookmark and a revert function
> should store more high-level arguments? For example, for
> 'project-find-regexp' it should be sufficient to store
> its argument 'regexp' together with 'default-directory'
> to reconstruct the previous xref buffer contents.
> Then it could store these arguments in a buffer-local variable
> that could be used to create a bookmark.
Yes, that's almost exactly what I did in my bookmarking implementation.
Only difference is I kept the whole project object instead of just
'default-directory', since different project types can use different
information. I'm attaching below the patch I applied in my local
branch, as a reference.
> PS: With C-u 'project-find-regexp' reads more arguments
> in the body, but such reading should be moved to the
> interactive form anyway like 'rgrep' does.
Agreed. This patch does that too:
--=-=-=
Content-Type: text/x-patch
Content-Disposition: attachment;
filename=0001-Support-bookmarking-project-find-regexp-results-buff.patch
From 5de2bfd3e2d672d0f955b916a200edc16dca6b07 Mon Sep 17 00:00:00 2001
From: Eshel Yaron <me@HIDDEN>
Date: Mon, 12 Feb 2024 18:38:36 +0100
Subject: [PATCH] Support bookmarking 'project-find-regexp' results buffer
* lisp/progmodes/project.el (xref-backend-apropos)
(xref-backend-context, xref-backend-restore): New methods.
(project-find-regexp, project-or-external-find-regexp): Use
'xref-make-fetcher' instead of a bespoke fetcher function to
facilitate bookmarking the results buffer.
* lisp/progmodes/xref.el (xref-bookmark-make-record): Use
strings for 'format-spec' specifications.
(xref-bookmark-jump): Autoload it.
(xref-show-xrefs): Make DISPLAY-ACTION argument optional.
(xref-make-fetcher): Autoload, and make BUFFER and POINT
arguments optional, default to the current buffer and point.
---
lisp/progmodes/project.el | 69 ++++++++++++++++++++-------------------
lisp/progmodes/xref.el | 14 +++++---
2 files changed, 45 insertions(+), 38 deletions(-)
diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
index 916a031ec60..6b0b4e86851 100644
--- a/lisp/progmodes/project.el
+++ b/lisp/progmodes/project.el
@@ -947,32 +947,44 @@ project-other-tab-command
(declare-function grep-read-files "grep")
(declare-function xref--find-ignores-arguments "xref")
+(cl-defmethod xref-backend-context ((_backend (head project)) _id _kind))
+(cl-defmethod xref-backend-restore ((_backend (head project)) _context))
+(cl-defmethod xref-backend-apropos ((backend (head project)) pattern)
+ (project--find-regexp-in-files pattern (project-files (cdr backend))))
+
+(cl-defmethod xref-backend-context ((_backend (head project-dir)) _id _kind))
+(cl-defmethod xref-backend-restore ((_backend (head project-dir)) _context))
+(cl-defmethod xref-backend-apropos ((backend (head project-dir)) pattern)
+ (project--find-regexp-in-files
+ pattern (project--files-in-directory (nth 1 backend) nil (nth 2 backend))))
+
+(cl-defmethod xref-backend-context ((_backend (head project-ext)) _id _kind))
+(cl-defmethod xref-backend-restore ((_backend (head project-ext)) _context))
+(cl-defmethod xref-backend-apropos ((backend (head project-ext)) pattern)
+ (let ((pr (cdr backend)))
+ (project--find-regexp-in-files
+ pattern (project-files pr (cons (project-root pr)
+ (project-external-roots pr))))))
+
;;;###autoload
-(defun project-find-regexp (regexp)
+(defun project-find-regexp (regexp &optional dir pattern)
"Find all matches for REGEXP in the current project's roots.
-With \\[universal-argument] prefix, you can specify the directory
-to search in, and the file name pattern to search for. The
+With \\[universal-argument] prefix, you can specify the DIR
+to search in, and the file name PATTERN to search for. The
pattern may use abbreviations defined in `grep-files-aliases',
e.g. entering `ch' is equivalent to `*.[ch]'. As whitespace
triggers completion when entering a pattern, including it
requires quoting, e.g. `\\[quoted-insert]<space>'."
- (interactive (list (project--read-regexp)))
- (require 'xref)
- (require 'grep)
- (let* ((caller-dir default-directory)
- (pr (project-current t))
- (default-directory (project-root pr))
- (files
- (if (not current-prefix-arg)
- (project-files pr)
- (let ((dir (read-directory-name "Base directory: "
- caller-dir nil t)))
- (project--files-in-directory dir
- nil
- (grep-read-files regexp))))))
- (xref-show-xrefs
- (apply-partially #'project--find-regexp-in-files regexp files)
- nil)))
+ (interactive (let* ((regexp (project--read-regexp))
+ (dir-pat (when current-prefix-arg
+ (cons (read-directory-name "Base directory: ")
+ (grep-read-files regexp)))))
+ (list regexp (car dir-pat) (cdr dir-pat))))
+ (xref-show-xrefs (xref-make-fetcher
+ (if dir
+ (list 'project-dir dir pattern)
+ (cons 'project (project-current t)))
+ regexp 'apropos regexp)))
(defun project--dir-ignores (project dir)
(let ((root (project-root project)))
@@ -987,20 +999,11 @@ project--dir-ignores
;;;###autoload
(defun project-or-external-find-regexp (regexp)
- "Find all matches for REGEXP in the project roots or external roots.
-With \\[universal-argument] prefix, you can specify the file name
-pattern to search for."
+ "Find all matches for REGEXP in the project roots or external roots."
(interactive (list (project--read-regexp)))
- (require 'xref)
- (let* ((pr (project-current t))
- (default-directory (project-root pr))
- (files
- (project-files pr (cons
- (project-root pr)
- (project-external-roots pr)))))
- (xref-show-xrefs
- (apply-partially #'project--find-regexp-in-files regexp files)
- nil)))
+ (xref-show-xrefs (xref-make-fetcher
+ (cons 'project-ext (project-current t))
+ regexp 'apropos regexp)))
(defun project--find-regexp-in-files (regexp files)
(unless files
diff --git a/lisp/progmodes/xref.el b/lisp/progmodes/xref.el
index 6841f93a9c2..2742cc56ea1 100644
--- a/lisp/progmodes/xref.el
+++ b/lisp/progmodes/xref.el
@@ -1049,8 +1049,8 @@ xref-bookmark-make-record
(user-error "Cannot bookmark due to unknown Xref backend"))
`(,(format-spec xref-default-bookmark-name-format
`((?i . ,xref--identifier)
- (?k . ,xref--kind)
- (?b . ,xref--backend)))
+ (?k . ,(symbol-name xref--kind))
+ (?b . ,(prin1-to-string xref--backend))))
,@(bookmark-make-record-default t)
(backend . ,xref--backend)
(context . ,(when (buffer-live-p xref--original-buffer)
@@ -1064,6 +1064,7 @@ xref-bookmark-make-record
(kind . ,xref--kind)
(handler . xref-bookmark-jump)))
+;;;###autoload
(defun xref-bookmark-jump (bookmark)
"Jump to Xref buffer bookmark BOOKMARK."
(let* ((backend (bookmark-prop-get bookmark 'backend))
@@ -1587,7 +1588,7 @@ xref--read-identifier-history
(defvar xref--read-pattern-history nil)
;;;###autoload
-(defun xref-show-xrefs (fetcher display-action)
+(defun xref-show-xrefs (fetcher &optional display-action)
"Display some Xref values produced by FETCHER using DISPLAY-ACTION.
The meanings of both arguments are the same as documented in
`xref-show-xrefs-function'."
@@ -1680,7 +1681,8 @@ xref--find-definitions
(xref--create-fetcher id 'definitions id)
display-action))
-(defun xref-make-fetcher (backend input kind identifier buffer point)
+;;;###autoload
+(defun xref-make-fetcher (backend input kind identifier &optional buffer point)
"Return fetcher function for xrefs of kind KIND for IDENTIFIER using BACKEND.
INPUT is the user input for the Xref operation, usually it is the same
@@ -1690,7 +1692,9 @@ xref-make-fetcher
The fetcher function returns a list of xrefs, and sets
`xref-fetcher-alist', which see."
- (let ((method (intern (format "xref-backend-%s" kind))))
+ (let ((method (intern (format "xref-backend-%s" kind)))
+ (buffer (or buffer (current-buffer)))
+ (point (or point (point))))
(lambda ()
(setq xref-fetcher-alist (list (cons 'original-buffer buffer)
(cons 'original-point point)
--
2.42.0
--=-=-=--
X-Loop: help-debbugs@HIDDEN
Subject: bug#68958: [PATCH] Support bookmarking Xref results buffers
Resent-From: Dmitry Gutov <dmitry@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 15 Feb 2024 17:58:01 +0000
Resent-Message-ID: <handler.68958.B68958.170801985931324 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 68958
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Eshel Yaron <me@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, 68958 <at> debbugs.gnu.org
Received: via spool by 68958-submit <at> debbugs.gnu.org id=B68958.170801985931324
(code B ref 68958); Thu, 15 Feb 2024 17:58:01 +0000
Received: (at 68958) by debbugs.gnu.org; 15 Feb 2024 17:57:39 +0000
Received: from localhost ([127.0.0.1]:56921 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1rafzP-000899-6S
for submit <at> debbugs.gnu.org; Thu, 15 Feb 2024 12:57:39 -0500
Received: from wout1-smtp.messagingengine.com ([64.147.123.24]:51727)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <dmitry@HIDDEN>) id 1rafzM-00088p-V1
for 68958 <at> debbugs.gnu.org; Thu, 15 Feb 2024 12:57:37 -0500
Received: from compute6.internal (compute6.nyi.internal [10.202.2.47])
by mailout.west.internal (Postfix) with ESMTP id C64A23200A01;
Thu, 15 Feb 2024 12:57:11 -0500 (EST)
Received: from mailfrontend1 ([10.202.2.162])
by compute6.internal (MEProxy); Thu, 15 Feb 2024 12:57:12 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc
:cc:content-transfer-encoding:content-type:content-type:date
:date:from:from:in-reply-to:in-reply-to:message-id:mime-version
:references:reply-to:subject:subject:to:to; s=fm2; t=1708019831;
x=1708106231; bh=EBggH70Wz8oBC0PisZUMw8QOX5jOJn9RnLtuDXVCISM=; b=
ZNJ8P30rdf3lcmPDCWZCHqiEFkdn96/OfCI0mRrcBjGwq7BgRSzWId2M7UPIFQGh
G7L4LlMKLqU08qLcATwarZN12zKoMvEbc2KvOxszXblZdypxex+3Gv077r4tiDKb
6xJ/bX0D+XwrLOvtnt9fAdnxyvfoNXhHstpBvMfrysiwVDXV5F3IVGCfjRaYW2y6
wP2DMSwQJBBjEL8hmPOhRfS5QP8oVoZEcqE0Pn1JthIzUQP9YlhP+9TUlfU7gY6x
r85CH4ZeS42r9US60XzPvYNBVhfwMJonRYLaMi8a6CFi9AjdObdWR4J1JTJQ3S1L
8zxD/vF7umAmVjVylxh+7w==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
messagingengine.com; h=cc:cc:content-transfer-encoding
:content-type:content-type:date:date:feedback-id:feedback-id
:from:from:in-reply-to:in-reply-to:message-id:mime-version
:references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy
:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1708019831; x=
1708106231; bh=EBggH70Wz8oBC0PisZUMw8QOX5jOJn9RnLtuDXVCISM=; b=N
TFc7xz3GGX8CLM6rjWJtp0wIOLmpq+HD8vyoq7IsXce8HutiOG/tC3mR0BkUBhBF
hf1r2d641DtK0MlCIGtuCBtZQl4nTCyHiTdu6h5YcGiILHslgKGmeXTUsAtmzDId
w20RUnkE1O35mVzdU+WNE3+MXMFcPl8bdL22qfPHwAgaStuBCo4ujDgmL++R3/VF
u5zIiJF5HAETnSv+mgPKD0MAN6D9YgnT9Xc+rxRWfC6cHwHIlRmJDiYNPkFARwJ5
YD4RNv2/GQ4UBM9TPJRbmQfZGokm+WwJXvGfHdEl3nE4kO/yZNL0w93YMt+tWJMA
A7Wu6+xhXJHWwdHBg3t6A==
X-ME-Sender: <xms:d1DOZSi74mAvUpYQXKJu18OQjbDqJiiWyH_esvmpQTbgBMeOQv08sg>
<xme:d1DOZTC8hXWZw8itHQ06o5rZ2-QUv5yFmcCtDrWMIoQo4lZWkpUsPe4E9PVrEMSgA
kSoVacsx4mvPi6vEc4>
X-ME-Received: <xmr:d1DOZaGYpERvkWvc11PPbn_mdJYK8fj52NyWz8bz2rsKO3KkFKzQ_H740L5QvoiKvYLn>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrvddtgddutdejucetufdoteggodetrfdotf
fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne
cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtvdejnecuhfhrohhmpeffmhhi
thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth
htvghrnhepteduleejgeehtefgheegjeekueehvdevieekueeftddvtdevfefhvdevgedu
jeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug
hmihhtrhihsehguhhtohhvrdguvghv
X-ME-Proxy: <xmx:d1DOZbQOhbLI4JnnQs0G_YxnDnVouFkO5dqmv2gQJ3btBY0rfvRgMg>
<xmx:d1DOZfy-EHBEa0MEDQPuApLijdNrCPTbxMN6wviWFYGYodptxzrHgQ>
<xmx:d1DOZZ5V7tucu3QxIUZla5dB_P2DWmLHeBDrE6UT4zBzKmZtmPcF_w>
<xmx:d1DOZYq8o67JZ4ypKU3tQkHpXlfvVUKC4COEb99Ye75Bl1w9ofQhiA>
Feedback-ID: i0e71465a:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu,
15 Feb 2024 12:57:10 -0500 (EST)
Message-ID: <622b208a-6e2a-4f47-b243-40846ec48df1@HIDDEN>
Date: Thu, 15 Feb 2024 19:57:08 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
References: <m1h6ilgxee.fsf@HIDDEN> <86le7wzcjj.fsf@HIDDEN>
<0b3f4669-180e-466f-96f3-7eeae994581f@HIDDEN>
<m1cyt35xrj.fsf@HIDDEN>
<b521e786-377c-4834-be68-87a824ae6384@HIDDEN>
<m14jee5341.fsf@HIDDEN>
<1bea3fe4-51aa-418b-a55f-f09d0a4c558e@HIDDEN>
<m1jzn9ewio.fsf@HIDDEN>
<653af486-3b3b-4270-8385-ee3af6639eb5@HIDDEN>
<m18r3ou9dx.fsf@HIDDEN>
From: Dmitry Gutov <dmitry@HIDDEN>
In-Reply-To: <m18r3ou9dx.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: -2.6 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.6 (---)
On 13/02/2024 09:10, Eshel Yaron wrote:
> Dmitry Gutov <dmitry@HIDDEN> writes:
>
>> On 12/02/2024 13:45, Eshel Yaron wrote:
>>
>>> I agree that redundant complexity is better avoided, but this is the
>>> simplest compatible extension to the API I came up with to implement
>>> this feature.
>>
>> If we're going to recommend the callers use the new capability, I'd
>> rather they didn't have to be redundant every time.
>
> Often callers can use xref-make-fetcher to make the fetcher function,
> and that takes care of the redundant work for them. That's was I did
> for project-find-regexp and friends in my working branch, works well :)
>
> [ BTW, while at it, I noticed that the docstring for
> project-or-external-find-regexp mentions a prefix argument, but the
> function doesn't actually handle one. ]
Thank you for noting, now fixed.
>> Though I'm not sure whether the fetcher should reach
>> xref-show-xrefs-function intact (simpler code, but a breakage in the
>> interface, which could be mended with catching
>> wrong-number-of-arguments), or like in this example, both the original
>> fetcher and the arguments should be passed through alist.
>>
>> Otherwise, the requirements on the arguments are the same (fetcher --
>> named function, args -- printability).
>
> That might work, although it seems rather difficult to explain such
> requirements, and it's difficult for callers to ensure or even check
> whether they're kept (how do you know if your argument is too big
> without printing it in advance?)
You can usually track that on the level of user input. A good rule of
thumb would be not to pass a generated list of files. And if some user's
interactive input string is veeeeeery long, well, whatever disk space is
wasted as a result is their own doing.
What's the alternative, though? Writing a separate bookmark storage
function for every sort of search? For project, lsp-mode/eglot (they
both have additional commands doing extra searches), etc?
And the return value of xref-backend-context (from your proposal) must
likewise be print-able and compact enough, right?
> Furthermore, IIUC, what you get is an opaque function and argument list,
> and the frontend cannot reason about these, it can only apply the
> function to these arguments to get a list of xrefs. In contrast,
> xref-fetcher-alist provides clear (documented) semantics.
Which will only work for Xref's own commands but not for any external
callers of xref-show-xrefs. Right?
> We use it for
> bookmarking first and foremost, but the frontend can legitimately use it
> for other stuff too, like showing some info in the mode line.
>
>> Also, I'm not sure how we're supposed to guarantee that
>> xref--original-buffer is live.
>
> In my patch, we don't guarantee that (see xref-bookmark-make-record).
> And that's fine, it's a best effort to give the backend all the context
> it might need. If there's no original buffer, we just don't save and
> restore that bit of context.
Okay, I see that. Basically, you bookmark the "original point" and then
restore it from xref-backend-restore. So this would work, most of the time.
> The backend can handle a nil CONTEXT
> argument in xref-backend-restore however it sees fit. By default, it
> does nothing.
I don't any LSP backend could handle nil, though. It would need
additional data, like the origin file name, the value of point, etc.
>> Is that for use with desktop-mode only?
>
> What do you mean? To be clear, this is unrelated to desktop-mode, or at
> least I didn't design/implement any of this with desktop-mode in mind.
I meant that if you require the original buffer to be available when the
bookmark is loaded, the easiest way to satisfy that is for desktop-mode
to be used. But I see you solved that in a different way.
>> And it seems like as soon as the buffer has some new changes, the
>> bookmark is likely to become invalid (the same value of point will
>> point to a different identifier).
>
> We don't keep the value of point as such, we use the standard bookmark
> facilities to save some context around point so we can relocate to the
> right place if something changes. If we can't find that context when
> restoring the bookmark, point is just left at the beginning of the
> *xref* buffer. That's also fine. Does that make sense?
I meant the position of point in the original buffer, not in the Xref
buffer, which is required for the Xref searches to work in LSP backends.
I suppose the same bookmark mechanism would be used, too, though.
X-Loop: help-debbugs@HIDDEN
Subject: bug#68958: [PATCH] Support bookmarking Xref results buffers
Resent-From: Eshel Yaron <me@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 15 Feb 2024 21:50:02 +0000
Resent-Message-ID: <handler.68958.B68958.170803379526469 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 68958
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Dmitry Gutov <dmitry@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, 68958 <at> debbugs.gnu.org
Received: via spool by 68958-submit <at> debbugs.gnu.org id=B68958.170803379526469
(code B ref 68958); Thu, 15 Feb 2024 21:50:02 +0000
Received: (at 68958) by debbugs.gnu.org; 15 Feb 2024 21:49:55 +0000
Received: from localhost ([127.0.0.1]:57628 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1rajc7-0006sl-Gq
for submit <at> debbugs.gnu.org; Thu, 15 Feb 2024 16:49:54 -0500
Received: from mail.eshelyaron.com ([107.175.124.16]:39484 helo=eshelyaron.com)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <me@HIDDEN>) id 1rajc5-0006se-QN
for 68958 <at> debbugs.gnu.org; Thu, 15 Feb 2024 16:49:50 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eshelyaron.com;
s=mail; t=1708033770;
bh=2iQ9zhqKpZHePyMTS4H4samTPmPk3Fp/5aVL6ldq1+c=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=xIVtHmPgUFHoSyhoUbNqc4Y2SZ+rpX+1qSC5gPxyWBMBqDgAhIaeWCvMZDOZaVcbn
GaQGQ5ECiXRbPmhTGT0xA3hqORuyIN98U841hx1sjCqV3SzHC8cPZo5e/EuZifCHFp
zSeQti2V8c0NhpoH58gl2Av9PXGdWWi/FEK8qH/+DV5c4h5fJOKqGJjFGz5uY/VZgC
IBHtEv7hPxDOxhAyxtaKEovdmhFy6zL47/LPUk6JOXv8Jx3XQ7bw2BzB5m13PDR6bo
IvcY8D0rhYxu9C0Mn6+0pkZhBHs68vCsZaT+Vh2r6D/aGhI+aFdNvcCJQnItdqsb6/
KKnWeXokXz7Og==
From: Eshel Yaron <me@HIDDEN>
In-Reply-To: <622b208a-6e2a-4f47-b243-40846ec48df1@HIDDEN> (Dmitry Gutov's
message of "Thu, 15 Feb 2024 19:57:08 +0200")
References: <m1h6ilgxee.fsf@HIDDEN> <86le7wzcjj.fsf@HIDDEN>
<0b3f4669-180e-466f-96f3-7eeae994581f@HIDDEN>
<m1cyt35xrj.fsf@HIDDEN>
<b521e786-377c-4834-be68-87a824ae6384@HIDDEN>
<m14jee5341.fsf@HIDDEN>
<1bea3fe4-51aa-418b-a55f-f09d0a4c558e@HIDDEN>
<m1jzn9ewio.fsf@HIDDEN>
<653af486-3b3b-4270-8385-ee3af6639eb5@HIDDEN>
<m18r3ou9dx.fsf@HIDDEN>
<622b208a-6e2a-4f47-b243-40846ec48df1@HIDDEN>
Date: Thu, 15 Feb 2024 22:49:26 +0100
Message-ID: <m1r0hdtn2x.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -1.9 (-)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.9 (--)
Dmitry Gutov <dmitry@HIDDEN> writes:
> On 13/02/2024 09:10, Eshel Yaron wrote:
>> Dmitry Gutov <dmitry@HIDDEN> writes:
>>
>>> Otherwise, the requirements on the arguments are the same (fetcher --
>>> named function, args -- printability).
>> That might work, although it seems rather difficult to explain such
>> requirements, and it's difficult for callers to ensure or even check
>> whether they're kept (how do you know if your argument is too big
>> without printing it in advance?)
>
> You can usually track that on the level of user input. A good rule of
> thumb would be not to pass a generated list of files. And if some
> user's interactive input string is veeeeeery long, well, whatever disk
> space is wasted as a result is their own doing.
I agree, that's a good heuristic.
> What's the alternative, though? Writing a separate bookmark storage
> function for every sort of search? For project, lsp-mode/eglot (they
> both have additional commands doing extra searches), etc?
I think we should have an extensible interface that covers the Xref
commands by default, and allows other callers of `xref-show-xrefs` to
override the default to suite their needs.
> And the return value of xref-backend-context (from your proposal) must
> likewise be print-able and compact enough, right?
Yes, you're right. By default, in my proposal, the return value of this
method is itself a bookmark record (pointing to the position where you
initiate the search), so we rely on the major mode of the original
buffer to define a reasonable `bookmark-make-record-function`. If a
backend overrides the default method, it also needs to take into account
these limitations, indeed.
>> Furthermore, IIUC, what you get is an opaque function and argument list,
>> and the frontend cannot reason about these, it can only apply the
>> function to these arguments to get a list of xrefs. In contrast,
>> xref-fetcher-alist provides clear (documented) semantics.
>
> Which will only work for Xref's own commands but not for any external
> callers of xref-show-xrefs. Right?
It doesn't work out of the box for external callers, but it isn't
strictly restricted to Xref commands either: it works for any caller of
`xref-show-xrefs` that defines a (possibly trivial) Xref backend, and
passes a fetcher function that sets `xref-fetcher-alist`.
`xref-make-fetcher` is supposed to make it easier to create the such a
fetcher function.
>> We use it for
>> bookmarking first and foremost, but the frontend can legitimately use it
>> for other stuff too, like showing some info in the mode line.
>>
>>> Also, I'm not sure how we're supposed to guarantee that
>>> xref--original-buffer is live.
>> In my patch, we don't guarantee that (see
>> xref-bookmark-make-record).
>> And that's fine, it's a best effort to give the backend all the context
>> it might need. If there's no original buffer, we just don't save and
>> restore that bit of context.
>
> Okay, I see that. Basically, you bookmark the "original point" and
> then restore it from xref-backend-restore. So this would work, most of
> the time.
>
>> The backend can handle a nil CONTEXT
>> argument in xref-backend-restore however it sees fit. By default, it
>> does nothing.
>
> I don't any LSP backend could handle nil, though. It would need
> additional data, like the origin file name, the value of point, etc.
Right. For Eglot, we cannot restore a bookmark with nil context, and we
also need to make sure we're connected to the server. Adding something
like the following in eglot.el seems to do the trick:
--8<---------------cut here---------------start------------->8---
(cl-defmethod xref-backend-restore ((_backend (eql eglot)) context)
(unless context
(error "No context available for restoring Xref search"))
(bookmark-handle-bookmark context)
(unless eglot--managed-mode
(apply #'eglot--connect (eglot--guess-contact))))
--8<---------------cut here---------------end--------------->8---
Received: (at control) by debbugs.gnu.org; 11 Feb 2025 19:50:19 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Feb 11 14:50:19 2025 Received: from localhost ([127.0.0.1]:58864 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1thwGx-0002mp-J1 for submit <at> debbugs.gnu.org; Tue, 11 Feb 2025 14:50:19 -0500 Received: from mail-ed1-x52d.google.com ([2a00:1450:4864:20::52d]:59519) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <stefankangas@HIDDEN>) id 1thwGv-0002h2-Jz for control <at> debbugs.gnu.org; Tue, 11 Feb 2025 14:50:18 -0500 Received: by mail-ed1-x52d.google.com with SMTP id 4fb4d7f45d1cf-5de6e26db8eso5755091a12.2 for <control <at> debbugs.gnu.org>; Tue, 11 Feb 2025 11:50:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1739303411; x=1739908211; darn=debbugs.gnu.org; h=to:subject:message-id:date:mime-version:from:from:to:cc:subject :date:message-id:reply-to; bh=P93tfYNgPO3P/VZQUdM8/7asYmS4NRHw4p+rIUFqOG4=; b=H946a9wSM289EKxJtpco29+jEmQs3WvUcqemiq7NZ5K2ylcxF6GAaZbzZWE+QZQn+7 dVYcsAeY/i/nR+6JGR7QNna+HQch44oqAt3hRdQ3qgNQp/OTPJDfVW+5HBvvxSINOVgo +aAwGYVuB0NKtyCZ43rDTZeuZeIzr5chR2kKsE56DVz0pnn2sbrbLerQU9XoH7NJhVZ+ +qSvpqSQCGjGzWub/aGAayYHued+q0Ct24VNSDMIf25UC1vhRFOqyvmJExy4lOjFxY7I TOC+40xSPyv+4IZlhppnggXH1GeriJzkB419RPjyZEZaR2o2zpGkLwQVkNnbm863A6aA 8xZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739303411; x=1739908211; h=to:subject:message-id:date:mime-version:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=P93tfYNgPO3P/VZQUdM8/7asYmS4NRHw4p+rIUFqOG4=; b=pVxAxLLquZMFdIc0N5EkoIzQh3Tu8XK7vi+qsVFP73jAefT1nOSy4xclU1OXlWLR/V iyEWcH+CAFri7klTi2LoguEaY5mzUnMUzWbH7zsTHHSiQXNyXBcWCmI3bMQq1r/jk4Bi PtjizVq1OGBZ/A5/EXeAPpL7Ry5HRfH1HepOmAqySFgTvoaGvvMsfTFfePpJ5KBqoCPx lrL0JvDWFsPXHcA/AhTrzGUYldAPutbfzKHLS6u/80BaU0rCceuWdE/Qq1ONCv5R4kLN oz8oqVLP6G46TG1q1R3YKbM4/05igVbdBkMuTjEucEaksHYv/3CNrU/4kqS61Ze+m0ZJ PaBg== X-Gm-Message-State: AOJu0YxByAmLB/eo3el2Qi48kprWGWUgtSy5f0yPwK5b/hpcGrlPF6mU 2gtU0BejdayLGfMni5QhvUmHnIBARWeVuCl0ZV5l/q69zV1A1VYpD5ewAfwO4+kDo6RYWCec9F7 UUAr2hsgUd/h0JHjVWfZjELg38KFRr3w1skQORg== X-Gm-Gg: ASbGncvjTRQpzPicARZZGhEi/rRMT5rxkiYsS1GY6mt3txYXx2a3yuRMuz3qla7cZGv 6LmeORc9Q+7M9+Im2vrAqMJydExyxTgpctQp6jN0vnERVaBgT/CnWinUT/9gZoQzVQq4qj4Eprg == X-Google-Smtp-Source: AGHT+IEJUnGveHSBskghIG9SfPhv71+iJzCCxChTB/nj0OvVH49tYvjBJ79CLdMvxka0oFaZluX8ePeEzAd3h/OK4Lo= X-Received: by 2002:a05:6402:460a:b0:5dc:58ad:b8d5 with SMTP id 4fb4d7f45d1cf-5deadd92acbmr406533a12.9.1739303411349; Tue, 11 Feb 2025 11:50:11 -0800 (PST) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Tue, 11 Feb 2025 11:50:10 -0800 From: Stefan Kangas <stefankangas@HIDDEN> MIME-Version: 1.0 Date: Tue, 11 Feb 2025 11:50:10 -0800 X-Gm-Features: AWEUYZmfb_5aTAYAAQzDk39I0av5BopOVfr6TLsiXx3p9TaaqtyEh70D0v35DyA Message-ID: <CADwFkmmukKznRByQ4TLA0waCF3m+-3yoT04XzLzNgJMuW1GXnw@HIDDEN> Subject: control message for bug #68958 To: control <at> debbugs.gnu.org Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) severity 68958 wishlist quit
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.