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#44611: Prefix arg for xref-goto-xref Date: Fri, 25 Dec 2020 16:49:39 +0200 Message-ID: <189506b0-deeb-5ff3-c129-b083268a3cf3@yandex.ru> 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> <834kkanh8c.fsf@gnu.org> 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="11429"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 Cc: juri@linkov.net, joaotavora@gmail.com, 44611@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Dec 25 15:50: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 1ksoPy-0002qY-Dw for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 25 Dec 2020 15:50:10 +0100 Original-Received: from localhost ([::1]:58870 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ksoPw-0001te-S7 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 25 Dec 2020 09:50:08 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54964) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ksoPq-0001tM-91 for bug-gnu-emacs@gnu.org; Fri, 25 Dec 2020 09:50:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:45451) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ksoPq-0004bU-0O for bug-gnu-emacs@gnu.org; Fri, 25 Dec 2020 09:50:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ksoPp-0005jf-Ut for bug-gnu-emacs@gnu.org; Fri, 25 Dec 2020 09:50: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: Fri, 25 Dec 2020 14:50: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.160890779122027 (code B ref 44611); Fri, 25 Dec 2020 14:50:01 +0000 Original-Received: (at 44611) by debbugs.gnu.org; 25 Dec 2020 14:49:51 +0000 Original-Received: from localhost ([127.0.0.1]:56997 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ksoPf-0005jC-25 for submit@debbugs.gnu.org; Fri, 25 Dec 2020 09:49:51 -0500 Original-Received: from mail-ej1-f45.google.com ([209.85.218.45]:36138) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ksoPc-0005iw-Rh for 44611@debbugs.gnu.org; Fri, 25 Dec 2020 09:49:49 -0500 Original-Received: by mail-ej1-f45.google.com with SMTP id lt17so6508321ejb.3 for <44611@debbugs.gnu.org>; Fri, 25 Dec 2020 06:49:48 -0800 (PST) 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=KylvGnfuhfGFwa0hBRhmu+I17FLMZ5Uk5t5Q8x8MSwA=; b=YIhWBzG9vTpoby2QNUKZIHyOWvc3q9jXajrlr3p+ovFntHZAXvwXQm+Ys3tWDSRscO ZpR8PFOHhU+0PDoIAU/FvooYIMGOGiIpQ4RncsODp6GDn7Qpcov+YYqWux4OpPKL8bkQ YRVA93HToD7XvvRXGx2NskX7T5OrDDKxOQwMhf4ZSfT3mUaRI3m2oALZlev6J6U7XquT mqz/Rl2CL4QPhJA31e5ioOqeCla9MSlec2cEsdW59jriVfKP446NL/jNoZuHPJEHlpMw EpveWts3hNhuDnXZ3HJCXRkC1sOANmPOw17Xq7Y4BJpnIt8b3P17kK/UGiBcB0UWfG22 XKog== 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=KylvGnfuhfGFwa0hBRhmu+I17FLMZ5Uk5t5Q8x8MSwA=; b=il5inpMpBY/Q7vVenj3IPJs2EuxBH+dB/6GtvkHn/tjnThDJJGesaVBi3/FoboU1im CTFz15/N9Zd9smzR3t3EOL+kzJlG/qlp1Saju/yhh9ArMYRwXAxO2c2L/zMisOLBHkcZ CRVNDZemyZHk+B/NxL/ld7pHbC8eYiaWmum9CdRe1nAfP/450Rzz7R24jBREMYuIZnR1 9d2VzDEpoH3V54tnv+2AR0bBQOL5LwcLegI3bmde6YP4mKQgBMTfIwnuC40DdVYVOAfv V7Q5ytriFf0erQfOoywD4TiqHmbtI1fn816T7WsYyuRvrZFlSSKh1/0pudVcjdo239rI JJcA== X-Gm-Message-State: AOAM531nOFvylehyEhU2fE+AHikArrcrMRVbY9t6p4HMZ3cVSHsFGitp qT8bdV+vuSosoMfl7YsVAS/LgxScBtD8sg== X-Google-Smtp-Source: ABdhPJyEluqT+GbLfdWJKs0OyUf4WNACGAoHJfzP20qQ3GyawDV8qQHo5m0P1Vxi/z4iK7Oed9Rsiw== X-Received: by 2002:a17:906:3111:: with SMTP id 17mr2558308ejx.152.1608907782604; Fri, 25 Dec 2020 06:49:42 -0800 (PST) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id s12sm33599824edu.28.2020.12.25.06.49.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 25 Dec 2020 06:49:41 -0800 (PST) In-Reply-To: <834kkanh8c.fsf@gnu.org> Content-Language: en-US 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:196702 Archived-At: On 25.12.2020 15:32, Eli Zaretskii wrote: >> 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? Yes, but that would involve creating a different implementation that renders in the same format, which we'll have to then keep in sync with the original implementation. I wouldn't mind, of course. If someone wants to bring Grep closer to Xref in presentation, and no code sharing is required, I don't even have to participate. Note that if Grep still doesn't share the underlying data format with Xref, xref-query-replace-in-results won't work. The jump-to-location commands will also need to have different implementations, so we won't be able to properly reuse the major mode either. > 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. The major mode also includes the bindings. Its rendering function also assumes synchronous execution currently, and the way it retrieves the data pieces to render depends on the data format. >> 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. xref-show-xrefs-function could have a Grep-like option. Although that one couldn't be the default, or else we'll force the xref commands to use it as well, which would be a step back. >> 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). This endeavor might need more of an encouragement than "I don't object". >>> 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? The format is not exactly the same: compilation log includes both the location (file name, line, column), the contents of a line, and the error message itself (which could span several lines). That doesn't fit the current data model. I mean, we could extend it, but IME the main complexity is not in how to make the buffer look similar enough (the main rendering function, xref--insert-xrefs, is just 50 lines long), but how to make the buffer work usefully overall. I.e. with compilation you usually want to see different kind of errors/warnings/infos denoted prominently, and you don't usually (ever?) want to search-replace across the results, like you'd want with Grep. OTOH, there was that idea about quick fixes which you might add with supporting compilers, and for which there is no counterpart in Grep search results. Finally, a compilation log can often include unstructured information like free-form logging, which is very often the case in rspec-compilation-mode, which is my main point of interaction with compilation-mode. Which would make the data format fall outside Xref's data model even more. As such, I'm probably not a good person to take point on developing that feature. >> 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? They are already fairly close. But there is some obvious usability benefit in having similar key bindings in modes that even serve different purposes: users will need to remember fewer bindings, and keep fewer differences in mind. Especially when the same key does one thing in one mode and something starkly different in another. The more different the two modes are, the more often we won't be able to manage that, of course. Finally, I don't make any plans like that because currently I can only focus on what looked like obvious missing spots in Emacs's built-in feature set (xref, project and etags-regen all came from that outlook). First I try to make the UI work well, and the unification can come later. Someday, someone will come and ask: Why do both project and dired call xref to perform their searches and render the results? That seems like a different kind of responsibility, and should be in a separate feature with well-defined semantics. Maybe even two different features. And then they'll hopefully lend some of their spare time to make that happen. To get there, though, the more comfortable we make the Xref UI for all current and future users, the better. >> 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? Well, even that is not a given for me (in a recent Reddit comment you said that you don't use any of the "alternative" packages created in the last 10 years, but I guess the built-in ones are exceptions). Or you could feel it's more-or-less good enough to replace the find-tag UI, or at least not painful enough to demand the new bindings be reversed. Or you could think it's better than find-tag, but grep-mode is still a better interface for what Grep does. Also, in my usage, xref-find-definitions almost never pops up the xref UI. xref-find-references does, though (though I don't use it often). And IIUC you don't really use project-find-regexp. I'm glad you do like it, though, if I understood you correctly now.