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: Mon, 12 Feb 2024 12:45:35 +0100 Message-ID: References: <86le7wzcjj.fsf@gnu.org> <0b3f4669-180e-466f-96f3-7eeae994581f@gutov.dev> <1bea3fe4-51aa-418b-a55f-f09d0a4c558e@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="10477"; 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 Mon Feb 12 12:53:09 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 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 ) 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 ) 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 ) 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 ) 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 Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 12 Feb 2024 11:53: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.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 ) 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 ) 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" 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:279888 Archived-At: Hi Dmitry, Dmitry Gutov 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