Hi!

I would suggest that xref should provide two kinds of searches:
>> one incremental (like `tags-search') and one `find-all' (like the
>> provided function).
>>
>
> Patch welcome, I suppose, but the current API is not amenable to such
> usage, so see below (++).


Unfortunately, I have very little time to do heavy lifting on Emacs anymore
(which is why recently stepped down maintaining the NS port). However, I
try to help out by providing user experience feedback, whenever I find
something that doesn't feel right.


* The xref UI window is not updated to reflect the current location. For
>> example, in a *grep* buffer, the cursor move and an arrow in the left
>> fringe reflect the current location.
>>
>
> Not updated when? When you call `next-error'? I imagine that's something
> to implement in that facility, then, so that every other mode implementing
> next-error-function benefits.


Yes. In a *grep* buffer, the point and arrow moves to reflect the current
entry.


* I like the touch that the matches in the *xref* buffer are syntax
>> highlighted. Unfortunately, not all matches are highlighted. It appears
>> as though only matches in previously viewed parts of source files retain
>> syntax highlighting.
>>
>
> Only those already visited by font-lock, yes.
>

It could be easily fixed by a call to `font-lock-ensure' (at least for
files already loaded into Emacs).


* `next-error' issued from an *xref* search don't reuse the source
>> windows (whereas a `next-error' issued from a grep buffer does).
>> * `next-error' in ChangeLog buffers cause Emacs to go to the
>> corresponding change. This makes it hard to step past irrelevant xref
>> matches if they occur a ChangeLog file.
>>
>
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=20489
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=20493
>
> Help welcome.


OK, I see that those problems are known. I hope that they get fixed, as
they are annoying.


+++ Using "etags *.h *.m *.c" in the Emacs "src" directory,
>> `(tags-search "nstrace")' find the first occurrence in 0.7 seconds,
>> whereas the new `tags-find-regexp' takes over 8 seconds to perform a
>> full search.
>>
>
> The previous UI has pathological cases as well. Take e.g. some project
> where "xyz" only occurs in the last file among those listed in TAGS.
> Searching through all of those, by opening each one in Emacs in sequence,
> with re-search-forward, is surely slower that using Grep.
>
> On the other hand, yes, the fact that the matches don't appear as soon as
> they're available, is a problem. Could you open a separate bug for that?
>

I'd rather prefer if you would file a bug, I don't know which part I should
refer to, as I've only used your experimental `tags-find-regexp' code.



> In other words, I would prefer if we would add an incremental xref
>> query-replace command along the lines I suggested for the search command
>> above.
>>
>
> It would need to know where to get the matches from. Or you'll end with N
> new query-replace commands, just like we have now (tags-query-replace,
> dired-do-query-replace-regexp, etc).


If an xref backend would supply a list of files, you can easily implement a
generic `xref-query-replace' command.

However, if a backend isn't file based, maybe a better interface would be
to ask it for "next buffer" and it can fill it with whatever content it
want's to. In this case, it would be possible to implement a generic
xref-query-replace.

Anyway, your suggestion with generators sounds interesting.


Finally, if all the tags commands should be made obsolete, their
>> documentations should be updated with references to the commands that
>> are intended to replace them.
>>
>
> We do that with "(declare (obsolete ...".
>

Ah, I see that some commands like `find-tag' is marked as obsolete, however
`tags-search', and a few others, are not.

    -- Anders