Re: Unified project interface

[Dmitry Gutov]

Hi Eric,

On 06/06/2015 03:32 PM, Eric Ludlam wrote:

> In general, if there is a proposed generic project root type I'll be
> happy to enabled EDE to supply data to it.

That's good.

> Alternately, if there is an
> interest in an EDE-lite where key functionality such as detection and
> providing a root path is pulled up into something that doesn't turn on
> all the other unwanted EDE features, I'd be happy to advise or help.
>
> For an example, in 25.x, in cedet/ede/generic.el, look for
> `ede-enable-generic-projects' for some simple definitions.  I'm sure the
> generic project type in EDE is overkill for what is wanted, so I'm
> assuming there would need to be a stripped down version.

While it looks pretty decent, I'm among those'd prefer to see CEDET 
moved out to GNU ELPA.

And anyway, it would be better to have the smallest possible API that, 
say, Projectile could implement without relying on EDE being present and 
loaded.

But any lessons EDE can teach us about making that API better, would be 
great to have.

> As a reminder, ede uses CLOS, so there is a base object representing the
> project, and you can run methods against it to get information which
> would be simple to expand to any type of desired generic interface.

I imagine the new API will work along the same principle, only using 
cl-generic instead of eieio.

Does EDE store information about paths outside of the current project 
root? Like linked projects, or C include directories, or load-path 
elements (if EDE supports Elisp projects)?

Does it allow to quickly grep across all of them, or use 
semantic-symref, again, across all of them?