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

[Dmitry Gutov <dgutov@yandex.ru>]

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.

> 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.

We won't be able to use rgrep on the resulting directories, but we'd 
still have to handle ignored files.

I'd rather project-ignores was powerful enough to describe the majority 
of cases, and xref-find-regexp knew how to interpret that list.

> Right. The elisp project backend is incomplete.

It's not a backend. Like described above, it would be hard to even write 
a reasonably efficient project-find-functions element for such a 
backend. What will it do? Recursively scan the VC repo for .el files?

> That's one problem with using two dispatching mechanisms; it's too easy
> to get mixtures of incomplete implementations that "seem to work".

I'd call it "composability". :)