[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Dmitry Gutov
Subject: bug#23179: 25.0.92; Restore `M-,' to continue etags search
Date: Sun, 3 Apr 2016 23:59:49 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0

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.


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?


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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]