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: Tue, 13 Feb 2024 08:10:50 +0100 Message-ID: References: <86le7wzcjj.fsf@gnu.org> <0b3f4669-180e-466f-96f3-7eeae994581f@gutov.dev> <1bea3fe4-51aa-418b-a55f-f09d0a4c558e@gutov.dev> <653af486-3b3b-4270-8385-ee3af6639eb5@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="16207"; 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 Tue Feb 13 08:12:10 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 1rZmxe-000406-Ak for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 13 Feb 2024 08:12:10 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rZmxG-0008IP-0S; Tue, 13 Feb 2024 02:11:46 -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 1rZmxE-0008IF-Lh for bug-gnu-emacs@gnu.org; Tue, 13 Feb 2024 02:11:44 -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 1rZmxE-000780-Dm for bug-gnu-emacs@gnu.org; Tue, 13 Feb 2024 02:11:44 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rZmxV-0004c0-L8 for bug-gnu-emacs@gnu.org; Tue, 13 Feb 2024 02:12:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eshel Yaron Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 13 Feb 2024 07: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.170780827317659 (code B ref 68958); Tue, 13 Feb 2024 07:12:01 +0000 Original-Received: (at 68958) by debbugs.gnu.org; 13 Feb 2024 07:11:13 +0000 Original-Received: from localhost ([127.0.0.1]:40879 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rZmwi-0004aj-Kl for submit@debbugs.gnu.org; Tue, 13 Feb 2024 02:11:13 -0500 Original-Received: from mail.eshelyaron.com ([107.175.124.16]:58374 helo=eshelyaron.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rZmwg-0004ac-Td for 68958@debbugs.gnu.org; Tue, 13 Feb 2024 02:11:11 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eshelyaron.com; s=mail; t=1707808253; bh=PdP7Gao8mMFezw08b+983okY/G5yJL/rjNzx7tMVrsc=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=sJl6ll26W/0FhEdXCz0O5LDdjke4dwHZH2SH2z5DEhpzOnJkZGssyv3W8VcKgM2YD CJoLBIUDDaBNiGkJMpnie/608ME/cu/WiXFrWcd7SgUB5MMkp++yof2hmwdDyhM9pg wrC7BLngEV6Dvxzi4ecp9kdEcgjLsmsn3Sj7kshdoBcxmFYCR9b90n3goJcStVkcnp U4lJFXWPhpTaz8IkRX5on6/9ec17377HZCHxPAZqBxD07bG3hOdMJ/2TuViaewPOKo T0xXA/Ubn18k80gNITxtB6ZwI7ru2HFroJeI9+nPHTK1sekXxFCZa3bxsGVWR58VBc dTofiXls1Atlw== In-Reply-To: <653af486-3b3b-4270-8385-ee3af6639eb5@gutov.dev> (Dmitry Gutov's message of "Tue, 13 Feb 2024 05:18: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:279945 Archived-At: Dmitry Gutov writes: > On 12/02/2024 13:45, Eshel Yaron wrote: > >> 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. > > If we're going to recommend the callers use the new capability, I'd > rather they didn't have to be redundant every time. Often callers can use xref-make-fetcher to make the fetcher function, and that takes care of the redundant work for them. That's was I did for project-find-regexp and friends in my working branch, works well :) [ BTW, while at it, I noticed that the docstring for project-or-external-find-regexp mentions a prefix argument, but the function doesn't actually handle one. ] >>> 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? > > A more concise yet backward-compatible approach could also look like > the below. > > Though I'm not sure whether the fetcher should reach > xref-show-xrefs-function intact (simpler code, but a breakage in the > interface, which could be mended with catching > wrong-number-of-arguments), or like in this example, both the original > fetcher and the arguments should be passed through alist. > > Otherwise, the requirements on the arguments are the same (fetcher -- > named function, args -- printability). That might work, although it seems rather difficult to explain such requirements, and it's difficult for callers to ensure or even check whether they're kept (how do you know if your argument is too big without printing it in advance?) Furthermore, IIUC, what you get is an opaque function and argument list, and the frontend cannot reason about these, it can only apply the function to these arguments to get a list of xrefs. In contrast, xref-fetcher-alist provides clear (documented) semantics. We use it for bookmarking first and foremost, but the frontend can legitimately use it for other stuff too, like showing some info in the mode line. > Also, I'm not sure how we're supposed to guarantee that > xref--original-buffer is live. In my patch, we don't guarantee that (see xref-bookmark-make-record). And that's fine, it's a best effort to give the backend all the context it might need. If there's no original buffer, we just don't save and restore that bit of context. The backend can handle a nil CONTEXT argument in xref-backend-restore however it sees fit. By default, it does nothing. > Is that for use with desktop-mode only? What do you mean? To be clear, this is unrelated to desktop-mode, or at least I didn't design/implement any of this with desktop-mode in mind. > And it seems like as soon as the buffer has some new changes, the > bookmark is likely to become invalid (the same value of point will > point to a different identifier). We don't keep the value of point as such, we use the standard bookmark facilities to save some context around point so we can relocate to the right place if something changes. If we can't find that context when restoring the bookmark, point is just left at the beginning of the *xref* buffer. That's also fine. Does that make sense?