[Top][All Lists]

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

Re: A unified project root interface

From: Eric M. Ludlam
Subject: Re: A unified project root interface
Date: Fri, 15 Mar 2013 20:47:25 -0400
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.3a1pre) Gecko/20091222 Shredder/3.1a1pre

On 03/13/2013 02:03 PM, David Engster wrote:
Eric M. Ludlam writes:
On 03/11/2013 02:57 PM, Lluís wrote:
CEDET provides this in two ways (as part of the EDE subsystem):

* If a Project.ede file exists, that's the root (similar to .dir-locals.el in
    this context)

* If signs of a "project-like" structure exist (e.g., (auto)makefiles, scons,
    java, etc), uses system-specific knowledge to automatically
detect the project
I'm commenting this because, first, managing projects is the purpose of EDE
(although it tries to do more than just identifying their root) and it's
integrated in Emacs; and second, because the auto-detection could help in making
the process simpler and, in the best case, auto-magical.

I, of course, agree with Lluis.  EDE is already setup to automatically
find projects as was requested.  Adding new projects through the
generic' system is a pretty simple prospect.

Yes, but we cannot envision all the kinds of projects people would want
and create those for them beforehand. And defining own projects with
ede-generic is simple, but not simple enough for end users. Let's take
the example for defining those simple projects in project-roots.el,
given by Sudish Joseph in this thread:

        ("Perl Project"
          :root-contains-files ("t" "lib")
          :on-hit (lambda (p) (message (car p))))

You can create a project like this with ede-generic, but then you have
to write a little defclass inheriting from ede-generic, call
ede-generic-new-autoloader, and to actually *do* something when the
project is loaded you have to define methods like
`ede-generic-setup-configuration'. This is just too much boilerplate for
such a simple thing like the above. Also, even most Emacs developers are
not familiar with the CLOS-like syntax that's needed to define those

There's no doubt that EDE can do all what's needed, but is has to be
wrapped in something that's easier to use, at least for simple stuff
like what project-roots.el does.

Ok, I can buy that. EDE was never simple. I just know that if an "official" project mechanism is built, I'll have some work to do. ;)

In particular, if a system for detecting projects is developed, it would be great if EDE could stop detecting projects (ie - I delete some code), and instead use a hook to say "hey, let me know if you found a project", after which it can do its bit of magic for projects it also knows about.

Also be aware that I ran into a lot of performance issues I had to work through with EDE project detection. Once other code starts asking where it is in a project, it's amazing how often that stuff gets called. A project cache is a super handy thing, and was one of the key performance improvements I made back when i was trying to speed up smart completion.


reply via email to

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