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" <bug-gnu-emacs@gnu.org>
Newsgroups: gmane.emacs.bugs
Subject: bug#68958: [PATCH] Support bookmarking Xref results buffers
Date: Mon, 12 Feb 2024 12:45:35 +0100
Message-ID: <m1jzn9ewio.fsf@dazzs-mbp.home>
References: <m1h6ilgxee.fsf@dazzs-mbp.home> <86le7wzcjj.fsf@gnu.org>
 <0b3f4669-180e-466f-96f3-7eeae994581f@gutov.dev>
 <m1cyt35xrj.fsf@dazzs-mbp.home>
 <b521e786-377c-4834-be68-87a824ae6384@gutov.dev>
 <m14jee5341.fsf@dazzs-mbp.home>
 <1bea3fe4-51aa-418b-a55f-f09d0a4c558e@gutov.dev>
Reply-To: Eshel Yaron <me@eshelyaron.com>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214";
	logging-data="10477"; mail-complaints-to="usenet@ciao.gmane.io"
User-Agent: Gnus/5.13 (Gnus v5.13)
Cc: Eli Zaretskii <eliz@gnu.org>, 68958@debbugs.gnu.org
To: Dmitry Gutov <dmitry@gutov.dev>
Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Feb 12 12:53:09 2024
Return-path: <bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org>
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 <bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org>)
	id 1rZUs1-0002WN-Jv
	for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 12 Feb 2024 12:53:09 +0100
Original-Received: from localhost ([::1] helo=lists1p.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.90_1)
	(envelope-from <bug-gnu-emacs-bounces@gnu.org>)
	id 1rZUrg-0006SU-4L; Mon, 12 Feb 2024 06:52:48 -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 <Debian-debbugs@debbugs.gnu.org>)
 id 1rZUre-0006S8-HH
 for bug-gnu-emacs@gnu.org; Mon, 12 Feb 2024 06:52:46 -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 <Debian-debbugs@debbugs.gnu.org>)
 id 1rZUre-0003ps-9C
 for bug-gnu-emacs@gnu.org; Mon, 12 Feb 2024 06:52:46 -0500
Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2)
 (envelope-from <Debian-debbugs@debbugs.gnu.org>) id 1rZUru-0003na-0y
 for bug-gnu-emacs@gnu.org; Mon, 12 Feb 2024 06:53:02 -0500
X-Loop: help-debbugs@gnu.org
Resent-From: Eshel Yaron <me@eshelyaron.com>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces@debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@gnu.org
Resent-Date: Mon, 12 Feb 2024 11:53:01 +0000
Resent-Message-ID: <handler.68958.B68958.170773876914535@debbugs.gnu.org>
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.170773876914535
 (code B ref 68958); Mon, 12 Feb 2024 11:53:01 +0000
Original-Received: (at 68958) by debbugs.gnu.org; 12 Feb 2024 11:52:49 +0000
Original-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@debbugs.gnu.org>)
 id 1rZUrh-0003mL-4l
 for submit@debbugs.gnu.org; Mon, 12 Feb 2024 06:52:49 -0500
Original-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@eshelyaron.com>) id 1rZUrf-0003m6-9D
 for 68958@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==
In-Reply-To: <1bea3fe4-51aa-418b-a55f-f09d0a4c558e@gutov.dev> (Dmitry Gutov's
 message of "Mon, 12 Feb 2024 01:01:28 +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" <bug-gnu-emacs.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/bug-gnu-emacs>,
 <mailto:bug-gnu-emacs-request@gnu.org?subject=unsubscribe>
List-Archive: <https://lists.gnu.org/archive/html/bug-gnu-emacs>
List-Post: <mailto:bug-gnu-emacs@gnu.org>
List-Help: <mailto:bug-gnu-emacs-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/bug-gnu-emacs>,
 <mailto:bug-gnu-emacs-request@gnu.org?subject=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:279888
Archived-At: <http://permalink.gmane.org/gmane.emacs.bugs/279888>

Hi Dmitry,

Dmitry Gutov <dmitry@gutov.dev> 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