[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Unified project interface

From: Dmitry Gutov
Subject: Re: Unified project interface
Date: Sat, 6 Jun 2015 21:44:12 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0

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?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]