From mboxrd@z Thu Jan  1 00:00:00 1970
Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail
From: Dmitry Gutov <dmitry@gutov.dev>
Newsgroups: gmane.emacs.bugs
Subject: bug#68958: [PATCH] Support bookmarking Xref results buffers
Date: Mon, 12 Feb 2024 01:01:28 +0200
Message-ID: <1bea3fe4-51aa-418b-a55f-f09d0a4c558e@gutov.dev>
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>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214";
	logging-data="26841"; mail-complaints-to="usenet@ciao.gmane.io"
User-Agent: Mozilla Thunderbird
Cc: Eli Zaretskii <eliz@gnu.org>, 68958@debbugs.gnu.org
To: Eshel Yaron <me@eshelyaron.com>
Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Feb 12 00:12:17 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 1rZIzg-0006p8-Id
	for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 12 Feb 2024 00:12:17 +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 1rZIzD-0007mq-Tu; Sun, 11 Feb 2024 18:11:47 -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 1rZIzB-0007mB-Sh
 for bug-gnu-emacs@gnu.org; Sun, 11 Feb 2024 18:11:45 -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 1rZIzB-0001Ig-KX
 for bug-gnu-emacs@gnu.org; Sun, 11 Feb 2024 18:11:45 -0500
Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2)
 (envelope-from <Debian-debbugs@debbugs.gnu.org>) id 1rZIzR-0000KX-K2
 for bug-gnu-emacs@gnu.org; Sun, 11 Feb 2024 18:12:01 -0500
X-Loop: help-debbugs@gnu.org
Resent-From: Dmitry Gutov <dmitry@gutov.dev>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces@debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@gnu.org
Resent-Date: Sun, 11 Feb 2024 23:12:01 +0000
Resent-Message-ID: <handler.68958.B68958.17076930871184@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.17076930871184
 (code B ref 68958); Sun, 11 Feb 2024 23:12:01 +0000
Original-Received: (at 68958) by debbugs.gnu.org; 11 Feb 2024 23:11:27 +0000
Original-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@debbugs.gnu.org>)
 id 1rZIys-0000Iy-G3
 for submit@debbugs.gnu.org; Sun, 11 Feb 2024 18:11:27 -0500
Original-Received: from wout2-smtp.messagingengine.com ([64.147.123.25]:51437)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <dmitry@gutov.dev>) id 1rZIyq-0000Ib-Jk
 for 68958@debbugs.gnu.org; Sun, 11 Feb 2024 18:11:25 -0500
Original-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)
Original-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
Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun,
 11 Feb 2024 18:01:29 -0500 (EST)
Content-Language: en-US
In-Reply-To: <m14jee5341.fsf@dazzs-mbp.home>
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:279878
Archived-At: <http://permalink.gmane.org/gmane.emacs.bugs/279878>

On 11/02/2024 19:21, Eshel Yaron wrote:
> Dmitry Gutov <dmitry@gutov.dev> 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.