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

[Anders Lindgren]

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