Re: cl-defgeneric vs random funcall in project.el

[Dmitry Gutov]

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.