From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#44611: Prefix arg for xref-goto-xref Date: Fri, 25 Dec 2020 15:32:51 +0200 Message-ID: <834kkanh8c.fsf@gnu.org> References: <87k0up68e4.fsf@mail.linkov.net> <99772eb6-5a4e-7cf6-259d-0e9429e6bf97@yandex.ru> <878sb3n0a9.fsf@mail.linkov.net> <48f942f9-a557-0185-25fe-612e78cd9071@yandex.ru> <875z67gd6z.fsf@mail.linkov.net> <72e9e5e9-651f-401f-2e26-faaac1b7fdb5@yandex.ru> <87v9cxleff.fsf@mail.linkov.net> <834kkhtaxm.fsf@gnu.org> <874kkgswg2.fsf@mail.linkov.net> <83v9cwsct7.fsf@gnu.org> <87k0tab3y0.fsf@mail.linkov.net> <83pn31rg5a.fsf@gnu.org> <877dp9ycq6.fsf@mail.linkov.net> <837dp8r250.fsf@gnu.org> <4a0c8870-e2e7-97c7-5808-afa704ebee13@yandex.ru> <83mty4pj0u.fsf@gnu.org> <878s9o1ck2.fsf@mail.linkov.net> <837dp7q3hi.fsf@gnu.org> <2e07d6d1-5a83-77c3-7915-8efa46fd47c3@yandex.ru> <83h7oanxoi.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26324"; mail-complaints-to="usenet@ciao.gmane.io" Cc: juri@linkov.net, joaotavora@gmail.com, 44611@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Dec 25 14:34:10 2020 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 1ksnEP-0006km-Qm for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 25 Dec 2020 14:34:09 +0100 Original-Received: from localhost ([::1]:38558 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ksnEO-0005QD-ST for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 25 Dec 2020 08:34:08 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46416) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ksnEI-0005Q6-5h for bug-gnu-emacs@gnu.org; Fri, 25 Dec 2020 08:34:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:45412) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ksnEH-0004ee-VU for bug-gnu-emacs@gnu.org; Fri, 25 Dec 2020 08:34:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ksnEH-000400-QM for bug-gnu-emacs@gnu.org; Fri, 25 Dec 2020 08:34:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 25 Dec 2020 13:34:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 44611 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: fixed Original-Received: via spool by 44611-submit@debbugs.gnu.org id=B44611.160890319915322 (code B ref 44611); Fri, 25 Dec 2020 13:34:01 +0000 Original-Received: (at 44611) by debbugs.gnu.org; 25 Dec 2020 13:33:19 +0000 Original-Received: from localhost ([127.0.0.1]:56957 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ksnDa-0003z4-Mr for submit@debbugs.gnu.org; Fri, 25 Dec 2020 08:33:19 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:53170) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ksnDY-0003yr-QU for 44611@debbugs.gnu.org; Fri, 25 Dec 2020 08:33:17 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:41313) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ksnDS-0004QI-GP; Fri, 25 Dec 2020 08:33:10 -0500 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4985 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1ksnDR-0006WB-Vm; Fri, 25 Dec 2020 08:33:10 -0500 In-Reply-To: (message from Dmitry Gutov on Fri, 25 Dec 2020 14:14:30 +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" Xref: news.gmane.io gmane.emacs.bugs:196701 Archived-At: > Cc: juri@linkov.net, joaotavora@gmail.com, 44611@debbugs.gnu.org > From: Dmitry Gutov > Date: Fri, 25 Dec 2020 14:14:30 +0200 > > > Then why do we need to have 2 separate modes? > > Well, Grep (and similar major modes people wrote in third-part packages) > do have a certain advantage: its execution is asynchronous, and the user > sees the results as soon as they arrive, even during a search over a > huge number of files. This can be implemented for xref, with certain > changes in the API, and with some use of threads, but that's still a > research problem. I'm probably missing something: why cannot we display the Grep hits received asynchronously in the Xref format? That would "just" mean changes in the filter function, right? IOW, I'm confused by your reference to asynchronous execution, which AFAIU has nothing to do with the form in which we present the results, nor with the major mode in which we put the buffer where the results are displayed. > > Are there any plans for > > replacing grep-mode with xref-mode in all the commands that use the > > former? > > I think we'd need a more concerted effort for something like that, > rather than just myself. To get such volunteers, making the current Grep > users even more satisfied with the current state of > xref--xref-buffer-mode is a good step, with much upside and really no > downside (at least to a point where we'd have to compromise on the design). > > I can outline a possible roadmap for improving xref, making its code > structure and data more logical (which includes moving some of them > out), but I don't think we'll throw out 'M-x grep' away anytime soon. We don't need to throw out Grep, not right away anyway. We just need a plan and a roadmap, and a decision that this is the long-term goal. And even when we have "M-x grep" showing results in Xref mode, it will still need at first be an optional feature, so people who are too used to the old presentation could have it. > Changing the latter to use the xref UI (which will have to be renamed > and become a separate package, BTW) is also likely to encounter much > bigger resistance than anything we've done in this area before: people > don't have the same expectations for new commands as they have for > existing ones, so I'm surprised you asked this (given your overall > backward compatibility stance, much stronger than mine). An optional feature cannot hurt, even if and when it becomes the default. Thus, there's no need for me to object to such long-term plans, if they are announced and proceed at a controlled pace (including the decision when it becomes the default). > > Do we also want to replace compilation-mode with xref-mode? > > That wouldn't work. I don't understand why. Can you explain? To clarify, all I'm talking about is a possibility to present compiler messages in Xref format. They are similar enough and show the same information, so why won't that work? > > If the plan is to make such replacements, that could be a good idea, > > and we can discuss the roadmap towards that goal. Such a roadmap > > should include a transition plan that will help people migrate as > > painlessly as possible, including the key bindings and the somewhat > > different looks. > > It's a big change, one I'm not at all confident we could manage before > Emacs 28 is released. It doesn't all have to happen in Emacs 28. > Do you really want this to happen, though? I don't know, I just had this thought and wanted to see what others think. However, if that isn't the plan, then I really don't understand the urge to make Xref be like Grep mode. If they are indeed different beasts, why make them similar? > I never got the impression that you enjoy using xref. Aside of the fact that I use it every hour of every day, you mean?