From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov 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: <86le7wzcjj.fsf@gnu.org> <0b3f4669-180e-466f-96f3-7eeae994581f@gutov.dev> 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 , 68958@debbugs.gnu.org To: Eshel Yaron 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: 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 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 ) 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 ) 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 ) 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 ) 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 Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 11 Feb 2024 23:12:01 +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.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 ) 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 ) 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: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledruddvgddtgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefkffggfgfuvfevfhfhjggtgfesthejredttddvjeenucfhrhhomhepffhmihht rhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrghtth gvrhhnpeetudeljeegheetgfehgeejkeeuhedvveeikeeufedtvddtveefhfdvveegudej heenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumh hithhrhiesghhuthhovhdruggvvh X-ME-Proxy: 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: 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:279878 Archived-At: On 11/02/2024 19:21, Eshel Yaron wrote: > 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). 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.