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

[Anders Lindgren]

On Sun, Apr 3, 2016 at 1:39 AM, Dmitry Gutov <dgutov@yandex.ru> wrote:

On 04/02/2016 09:58 AM, Eli Zaretskii wrote:

But we could have a tags-only command that presented an xref UI, I
think.  (Its name could be "tags-search" ;-)

Probably not tags-search; we're only deprecating some etags commands, but not removing them (yet?). And why is etags so special that it needs its own find-regexp command, but other backends don't?

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.

 

Dmitry:

Anyway, this should get you going: [tags-find-regexp]

Eli:

> Anders, can you see if this provides a solution to your problem?

I gave the code a test. It's a step in the right direction. However, I found some problems with the approach (even though not all are caused by xref):

* Unlike `tags-search', it search through all source files before presenting the first match. The traditional `tags-search' stop of the first match, and continue searching when the used pressed `M-,'. The effect is that it becomes much, much slower to find the first match [+++]. I would suggest that xref should provide two kinds of searches: one incremental (like `tags-search') and one `find-all' (like the provided function). You could think of `isearch' vs. `occur'. It would be fine with me if `next-error' would be used to restart the incremental search (even though I would probably bind it to `M-,').

* There is no need for a xref UI window when doing an incremental search or query-replace. It just occupies precious screen real estate.

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

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

* `next-error' issued from an *xref* search don't reuse the source windows (whereas a `next-error' issued from a grep buffer does). I use six side-by-side windows, and if I step through matches found across several source files, after a while all windows will be occupied by source files where matches were found.

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

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

John:

and what is the equivalent of tags-query-replace?

Dmtry:
> 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. `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.

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.

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.

    -- Anders