From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#35702: xref revert-buffer Date: Fri, 24 May 2019 15:57:03 +0300 Message-ID: <710f0ac1-80d7-6db8-7653-c58f93b6f4ab@yandex.ru> References: <87tvdzv4m2.fsf@mail.linkov.net> <838suw5jvh.fsf@gnu.org> <835zq059az.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="88534"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 Cc: 35702@debbugs.gnu.org, juri@linkov.net To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri May 24 15:15:30 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hUA2j-000Mml-Ls for geb-bug-gnu-emacs@m.gmane.org; Fri, 24 May 2019 15:15:29 +0200 Original-Received: from localhost ([127.0.0.1]:54478 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hUA2i-0000sx-GE for geb-bug-gnu-emacs@m.gmane.org; Fri, 24 May 2019 09:15:28 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:58688) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hUA1V-0007mH-R3 for bug-gnu-emacs@gnu.org; Fri, 24 May 2019 09:14:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hU9lp-0007Cd-TU for bug-gnu-emacs@gnu.org; Fri, 24 May 2019 08:58:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:60937) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hU9lp-0007CX-Pt for bug-gnu-emacs@gnu.org; Fri, 24 May 2019 08:58:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hU9lp-00017T-Of for bug-gnu-emacs@gnu.org; Fri, 24 May 2019 08:58:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 24 May 2019 12:58:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 35702 X-GNU-PR-Package: emacs Original-Received: via spool by 35702-submit@debbugs.gnu.org id=B35702.15587026424238 (code B ref 35702); Fri, 24 May 2019 12:58:01 +0000 Original-Received: (at 35702) by debbugs.gnu.org; 24 May 2019 12:57:22 +0000 Original-Received: from localhost ([127.0.0.1]:46246 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hU9lC-00016I-8P for submit@debbugs.gnu.org; Fri, 24 May 2019 08:57:22 -0400 Original-Received: from mail-wm1-f44.google.com ([209.85.128.44]:38728) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hU9l7-00015y-5S for 35702@debbugs.gnu.org; Fri, 24 May 2019 08:57:19 -0400 Original-Received: by mail-wm1-f44.google.com with SMTP id t5so9132435wmh.3 for <35702@debbugs.gnu.org>; Fri, 24 May 2019 05:57:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=YhaEpahzchnOFh4FeDIjgXBcT3e8xoxjcTq6EiRh4Zk=; b=s+Lyk+QRcSMEqhW4olwFc7oYnF3L95C6upuQCa9sguLjL1vVcO3FvMXSXVZoL01fIB 8EaGofb6VdSr7ErV4bis7MfjJ6/UXC3V4Qzp6+94B1kUh1POw/oLcNCfoHOSW5QymKqW mKz1P3Pd0SaUzOV+f4GjHrgGM2bL+f80sPzSQrOFY7sY0wL0jHuM0FG0c1fta2lgVN2f yqGRNwvSxCnbC2qEixvMazqtcHbAac2f7FxDmNy/z+I5mI6yOV0ZjoTdTG8SGxDKdEs3 OjqTzp4j9Do340JB5lo6R5n7NqGQ51PPLkZPMTxitFPCf5+0DFyPVycM0bEDZDAtPmmz Q1RA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=YhaEpahzchnOFh4FeDIjgXBcT3e8xoxjcTq6EiRh4Zk=; b=oFRlK8prPolMuTglITd45P6U42CQFlO0OzPDuveGTibLmjEY43982vo+raGuBhXlCG ReW6dF3ff+DXXPC3L1FBcWKzk2t9J7I5o/NriP2C3knlqT9pP9eEDjRqJrhkzhx6DGHk Z2z/J9XlhjCyiN4MI7QgfVvJJNJn9cHm2dnkwx1nFWSaMJRIs3M5FG/rt8id1lUAf0iY edEkdimzj42G+/a4GRwZuH+p49A1eeod9uePFzX/+cC27sptq9JQwsDySBWSBfLTpxZ+ deMFnXGP5NIp76KN5t8hj1/Oa8gfdCQEAaydx3uEyu/IN5NpSDt52G32QssRnq1kzje+ HZ+w== X-Gm-Message-State: APjAAAXru1sW3uw6RWHUx96+0BB3ou0GP4XiEgIKhcv7OrYngu9WiAAj b18ns4v1Lwyt8jELxZrr6UU= X-Google-Smtp-Source: APXvYqwJLsTUozvrrWuPLssGJHYNjsHvY/MbG57eVQvp/ibb4azn7iD9n70vwzX7tYhrunUbx/JBJQ== X-Received: by 2002:a05:600c:114f:: with SMTP id z15mr2077982wmz.104.1558702629695; Fri, 24 May 2019 05:57:09 -0700 (PDT) Original-Received: from [192.168.0.195] ([109.110.245.170]) by smtp.googlemail.com with ESMTPSA id g127sm1783327wme.21.2019.05.24.05.57.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 May 2019 05:57:05 -0700 (PDT) In-Reply-To: <835zq059az.fsf@gnu.org> Content-Language: en-US X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 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.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:159709 Archived-At: On 24.05.2019 15:25, Eli Zaretskii wrote: >>> Thanks, but that changeset has a few problems: >>> >>> . the new command xref--revert-xref-buffer uses an internal name, >> >> Is that a problem by itself? We have other bindings that use internal >> command names as well. > > That's a problem, yes. Commands shouldn't be internal functions, by > their very definition. I've been kind of using it as a means of denoting "we're free to change it later", which is, of course, not great for a user, but I don't feel like we're settled on a final UI. If we have a rule about private commands, though, let's fix them. But I'd prefer to do it a bit later, in a separate discussion. >>> and has no doc string >> >> How about something like: >> >> Refresh the search results by repeating the search. > > Given that it doesn't, at least after M-., this sounds like not all > the truth. Can it be more detailed? The truth is, most xref datasets support refreshing, but some don't. At least xref-find-definitions doesn't. I'm not sure we should document that in the command's docstring, though, because I think we'll end up with a more different UI for xref-find-definitions results, with a different major mode and a keymap where 'g' is simply not bound. >>> . neither NEWS nor the user manual document the 'g' key in XREF >>> buffers >> >> I can add the NEWS entry. > > Please do, and thanks. OK. Does it have to mention the command name? Here's what I have: ** Xref *** Refreshing the search results When an Xref buffer shows search results (e.g. from xref-find-references or project-find-regexp) you can type 'g' to repeat the search and refresh the results. >>> . it looks like this new command is not useful after M-., because I >>> get an error message when I try using it (perhaps this is because >>> I didn't understand its use case due to lack of docs) >> >> It has been a deliberate choice to simplify the implementation. IME, you >> don't ever want to refresh the list of definitions. > > Well, one situation where I'd like to refresh is when the TAGS file > was updated. It could mean that more identifiers matching the search > string are now known. Right, but how often would the event of updading the TAGS file with coincide with you wanting to refresh the xref-find-definitions results? Wouldn't you just do the search again with 'M-.'? This command has the easiest keybinding. >> But for other search results (references, apropos, >> project-find-regexp, dired-do-find-regexp) it's a lot more common. > > At the very least, this should be reflected in the doc string. Given that we're dealing with a certain level of abstration, and the list of commands using Xref is not limited, how would you phrase it? >> Commit 49a363c875 also brings in another difference between the >> behaviors of xref-find-definitions and xref-find-references: the latter >> now shows the xref buffer even when there is just one hit. > > This should arguable be in NEWS. How about: *** New variable 'xref-show-definitions-function' It encapsulates the logic pertinent to showing the result of xref-find-definitions. The user can change it to customize its behavior and the display of results. *** Search results show the buffer even for one hit The search-type Xref commands (e.g. xref-find-references or project-find-regexp) now show the results buffer even when there is only one hit. This can be altered by changing xref-show-xrefs-function. You can probably see a certain level of duplication there, though. >> Do you have a better idea now? > > Only slightly so. The code still doesn't speak to me, but I guess > there isn't much that can be done about that. This idea is pretty simple: instead of passing a list of search results to xref--show-xrefs, we pass an anonymous function that can be called to do the search, as well as repeat it, and returns the said list.