From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eshel Yaron via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#68958: [PATCH] Support bookmarking Xref results buffers Date: Sun, 11 Feb 2024 18:21:02 +0100 Message-ID: References: <86le7wzcjj.fsf@gnu.org> <0b3f4669-180e-466f-96f3-7eeae994581f@gutov.dev> Reply-To: Eshel Yaron Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3416"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Eli Zaretskii , 68958@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Feb 11 18:22:31 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1rZDXD-0000hH-7u for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 11 Feb 2024 18:22:31 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rZDWd-0000YR-TW; Sun, 11 Feb 2024 12:21:55 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rZDWV-0000XB-85 for bug-gnu-emacs@gnu.org; Sun, 11 Feb 2024 12:21:48 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rZDWT-0003rz-QB for bug-gnu-emacs@gnu.org; Sun, 11 Feb 2024 12:21:46 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rZDWk-0000FM-2L for bug-gnu-emacs@gnu.org; Sun, 11 Feb 2024 12:22:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eshel Yaron Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 11 Feb 2024 17:22:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 68958 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 68958-submit@debbugs.gnu.org id=B68958.1707672086859 (code B ref 68958); Sun, 11 Feb 2024 17:22:02 +0000 Original-Received: (at 68958) by debbugs.gnu.org; 11 Feb 2024 17:21:26 +0000 Original-Received: from localhost ([127.0.0.1]:33259 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rZDWA-0000Di-0l for submit@debbugs.gnu.org; Sun, 11 Feb 2024 12:21:26 -0500 Original-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 ) id 1rZDW6-0000DV-1m for 68958@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== In-Reply-To: (Dmitry Gutov's message of "Sun, 11 Feb 2024 17:34:57 +0200") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:279853 Archived-At: Dmitry Gutov 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...