[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: cl-defgeneric vs random funcall in project.el
From: |
Dmitry Gutov |
Subject: |
Re: cl-defgeneric vs random funcall in project.el |
Date: |
Fri, 31 Jul 2015 03:37:58 +0300 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:40.0) Gecko/20100101 Thunderbird/40.0 |
On 07/31/2015 02:33 AM, Stephen Leake wrote:
If the elisp project backend just used load-path as project-search-path,
what desired functionality would you lose?
xref-find-references won't search inside the current project root.
That's about all project-search-path is currently used for, but
hopefully other uses will crop up in the future. They would fail similarly.
You have talked about limiting xref-find-regexp to some subset of the
files that are visible thru load-path; can you give a concrete
use case for that?
Maybe if we have project-find-regexp-in-roots, it will only search
inside project-roots. And project-find-regexp will search inside roots +
search-path. It's unrelated to the issue above.
Well, we obviously disagree; every project manager _I've_ worked with
already produces a flat list.
I've addressed that in the other message, I think.
I don't understand why you are so dead set against supporting those
project managers.
One might call "always recursing" the "modern" mindset. For instance,
when calling Ag (a popular recent re-implementation of Grep), you have
to make extra effort *not* to recurse. There no corresponding option, even.
As long as I have the ability to override sufficient project and xref
features so I can write backends for the project managers I use, I'm ok.
It would be nice if more of the utilities were able to handle flat
paths, but I can always re-implement them.
I hope you'll consider whether recursing is too harmful, in each case.
We won't be able to use rgrep on the resulting directories,
You can use grep; what's wrong with that?
Not "rgrep". Instead of calling find constructed command-line arguments
once and collecting results, you'll have to call grep for each directory
you're interested in. And instead of find+grep, one could use Ag.
but we'd still have to handle ignored files.
That's no harder with a flat path than with a recursive path.
I'm sure it'll be more involved than the current implementation of
xref--rgrep-command.
- Re: cl-defgeneric vs random funcall in project.el, (continued)
- Re: cl-defgeneric vs random funcall in project.el, Stephen Leake, 2015/07/29
- Re: cl-defgeneric vs random funcall in project.el, Dmitry Gutov, 2015/07/29
- Re: cl-defgeneric vs random funcall in project.el, Stephen Leake, 2015/07/30
- Re: cl-defgeneric vs random funcall in project.el, Dmitry Gutov, 2015/07/30
- Re: cl-defgeneric vs random funcall in project.el, Stephen Leake, 2015/07/30
- Re: cl-defgeneric vs random funcall in project.el, Stephen Leake, 2015/07/30
- Re: cl-defgeneric vs random funcall in project.el, Dmitry Gutov, 2015/07/30
- Re: cl-defgeneric vs random funcall in project.el, Stephen Leake, 2015/07/30
- Re: cl-defgeneric vs random funcall in project.el, Dmitry Gutov, 2015/07/30
- Re: cl-defgeneric vs random funcall in project.el, Stephen Leake, 2015/07/30
- Re: cl-defgeneric vs random funcall in project.el,
Dmitry Gutov <=
- Re: cl-defgeneric vs random funcall in project.el, Stephen Leake, 2015/07/31
- Re: cl-defgeneric vs random funcall in project.el, Dmitry Gutov, 2015/07/31
- Re: cl-defgeneric vs random funcall in project.el, Stefan Monnier, 2015/07/30