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

[Stephen Leake <stephen_leake@stephe-leake.org>]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 07/30/2015 06:29 PM, Stephen Leake wrote:
>
>> The point of a "project backend" is that it knows _everything_ about the
>> project. No stray hooks for users to pervert things.
>
> The problem is I (and others) have a lot of Elisp projects which don't
> adhere to some particular structure. No particular project files,
> aside from a .git repo, and maybe Makefile, or maybe some other -file.
>
> It's not even easy to identify it: maybe there are some .el files in
> the root directory, but they might all be in a subdirectory.
>
> I want to support this use case.

Ok.

What does "support" mean here?

If the elisp project backend just used load-path as project-search-path,
what desired functionality would you lose?

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?

>> I would write the vc implementation of project-search-path to return a
>> flat list of all the directories under the vc root.
>
> The flat list is really out of the question. It really goes against my
> intuition and every project backend will have to implement the logic
> of producing this flat list based on some roots and a list of ignores.

Well, we obviously disagree; every project manager _I've_ worked with
already produces a flat list.

I don't understand why you are so dead set against supporting those
project managers.

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.

> We won't be able to use rgrep on the resulting directories, 

You can use grep; what's wrong with that?

> but we'd still have to handle ignored files.

That's no harder with a flat path than with a recursive path.

-- 
-- Stephe