|
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?
[Prev in Thread] | Current Thread | [Next in Thread] |