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

[Dmitry Gutov]

On 04/04/2016 11:21 AM, Anders Lindgren wrote:

> I have tried all the the functions you have suggested, but I didn't get
> any of them to perform like I wanted to. Of course, I didn't have time
> to dig into each one of them, so that, for example,
> `project-or-external-find-regexp' asked for a new project root directory
> and then failed to turn up any matches I put it aside.

Project commands just need a version-controlled directory to be called 
from. Are you not using version control for the project in question?

>     "redo this process"? Which one?
>
>
> The process of deciding which files and directories should be included
> in a "project". If you use TAGS, you typically do that from an external
> script cherry-picking directories and files. You don't want to do that a
> second time using some other kind of project manager.

Fair enough. But you'll also miss out on e.g. project-find-file.

We've been considering to approach this duplication of effort from the 
other direction: augmenting the project API with information necessary 
to generate a TAGS file.

>     Yes, there probably is a list of files in there a backend could
>     search, but it should be specified better than that. Search only
>     inside source code, but not documentation, resources, etc? Including
>     any external files that do not belong to this project (try imagining
>     a different xref backend for C code; it would probably include the
>     installed libraries)?
>
>     And again, what do you see as the main advantage of the new command
>     over project-or-external-find-regexp?
>
>
> The advantage over `tags-search' (which I use today) is that I would be
> able to use another, more powerful, underlying database.

That's not the question I asked. What's the advantage over 
project-or-external-find-regexp, at least when it works?

You've also never answered the questions about the command's semantics, 
above. If you want to see xref-find-regexp, I suggest you do that.

> E.g. TAGS does
> not manage references to objects whereas systems like "kythe" does.

That's one advantage to using a generic API like xref. I don't think 
it'll help much with xref-find-regexp, though: you're not just looking 
for references, it's a full-text regexp search.

> I mean the source buffer. Yes, `next-error' is a good candidate. (It's
> key binding is somewhat clumsy though, if you need to skip past several
> matches.)

I bind them to `M-n' and `M-p'. Luckily, they're not occupied by default.