GNU bug report logs - #44611
Prefix arg for xref-goto-xref

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 44611 <at> debbugs.gnu.org, joaotavora <at> gmail.com, juri <at> linkov.net
Subject: bug#44611: Prefix arg for xref-goto-xref
Date: Fri, 25 Dec 2020 16:49:39 +0200

On 25.12.2020 15:32, Eli Zaretskii wrote:
>> Cc: juri <at> linkov.net, joaotavora <at> gmail.com, 44611 <at> debbugs.gnu.org
>> From: Dmitry Gutov <dgutov <at> yandex.ru>
>> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.