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

[Dmitry Gutov]

On 08/01/2015 01:21 PM, Stephen Leake wrote:

> I want to ensure the core project API does not prevent me from writing
> the backends I want. It must also provide sufficient reason for me to
> use it; the fewer features I need that it has, the less reason I have to
> use it.

I think the API is sufficiently powerful for that already (flat vs 
recursive is the main unresolved issue). As for features, hopefully the 
list will grow, but many of them can come, eventually, from third-party 
packages.

> Is it a problem if they are present for others to use?
>
> We are discussing a core Emacs feature that will be used by many people;
> it cannot cater to only your personal opinions.

So far it's mostly you and me in this discussion. But there are existing 
packages that implement project support for Emacs, and the ones I've 
used (Projectile and Eproject) don't work like that either.

> > What you've described here, could be a separate project backend. One
> > you're welcome to write.
>
> Any backend that supports project files will need functions like these;
> project files are precisely centralized manual configuration.

Not at all, they need variables. You can easily set the variables from 
.dir-locals.el, and any Emacs-wielding team member on the same project 
will use them automatically.

So far I'm fuzzy on whether the variables should be global, or 
project-vc specific. Probably the latter.

> So they belong in the root class.

I'm pretty sure you expend a lot more effort on parsing any given kind 
of project file, than storing ignores or search-path would take.

> If I end up writing everything in the backend, there's no point in using
> the "unified project interface".

It's an interface, like the "I" in API. Backends implement a set of 
methods that other functions can use.