[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: Mon, 4 Apr 2016 14:00:07 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0

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

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

reply via email to

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