bug#23179: 25.0.92; Restore `M-,' to continue etags search

[Dmitry Gutov <dgutov@yandex.ru>]

On 04/03/2016 09:32 PM, Anders Lindgren wrote:

> Ideally, xref should define a regexp search command that work with all
> backends. The only thing tags-specific in your code is getting the list
> of files -- if you would expand the xref backend interface with a
> corresponding function it would work with all backends.

I'm still waiting for the specification, including a reply to 
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=23179#47.

> 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 (++).

> * 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.

> * 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.

> * `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.

> +++ 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?

(++)

If your sole goal is to implement an incremental search UI, I fear the 
change to the xref API will become needlessly complex.

I think we should be able to extend the API to return some concurrency 
data structure, like a generator, using generator.el. I haven't 
investigated that yet (+++), and I'd welcome someone else taking the charge.

(+++) Is is feasible to turn Grep output into a generator? Is the result 
easy to render in an xref buffer, while indicating that the search is 
not yet done? Is the generator's overhead small enough in most cases?

>> xref-query-replace-in-results
>
> This is not quite true. `tags-query-replace' do an incremental search
> and replace in the source files referred to by a tags file directly.

The word "equivalent" doesn't necessarily imply the same UI.

> `xref-query-replace-in-results' requires a user to first do a search (to
> get stuff into the xref buffer), then run the command to replace. It
> sounds very awkward to me.

It looks very natural to me. And considering it handles different result 
sets, in the end you have N+1 command, rather than 2N commands, for N 
kinds things to search in.

> 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).

> 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 ...".