[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
matches.)
I bind them to `M-n' and `M-p'. Luckily, they're not occupied by default.
- bug#23179: 25.0.92; Restore `M-,' to continue etags search, (continued)
- bug#23179: 25.0.92; Restore `M-,' to continue etags search, John Wiegley, 2016/04/02
- bug#23179: 25.0.92; Restore `M-,' to continue etags search, Dmitry Gutov, 2016/04/02
- bug#23179: 25.0.92; Restore `M-,' to continue etags search, John Wiegley, 2016/04/03
- bug#23179: 25.0.92; Restore `M-,' to continue etags search, Dmitry Gutov, 2016/04/03
- bug#23179: 25.0.92; Restore `M-,' to continue etags search, John Wiegley, 2016/04/03
- bug#23179: 25.0.92; Restore `M-,' to continue etags search, Dmitry Gutov, 2016/04/03
- bug#23179: 25.0.92; Restore `M-,' to continue etags search, Eli Zaretskii, 2016/04/03
- bug#23179: 25.0.92; Restore `M-,' to continue etags search, Eli Zaretskii, 2016/04/03
- bug#23179: 25.0.92; Restore `M-,' to continue etags search, Dmitry Gutov, 2016/04/02
- bug#23179: 25.0.92; Restore `M-,' to continue etags search, Anders Lindgren, 2016/04/04
- bug#23179: 25.0.92; Restore `M-,' to continue etags search,
Dmitry Gutov <=