[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: Sat, 23 Mar 2013 13:10:20 -0400
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.3a1pre) Gecko/20091222 Shredder/3.1a1pre

On 03/22/2013 04:30 PM, David Engster wrote:
Eric M. Ludlam writes:
On 03/21/2013 12:32 PM, David Engster wrote:
And what would happen when `ede-check-for-vcs-dirs' returns t?  Would
that load EDE then, or would we try to go on to provide the basic
functionality (like getting the root) with a class-less version?

I think this will be a bit of a challenge.  The project detection, and
then project hash are the key important pieces.  If the goal is to get
something that will be dumped w/ Emacs, and Fast, we'd need to start
by refactoring ede/files.el to split out the parts that track the
directory-to-project associations from all the misc EDE related file
finding routines.

Frankly, I don't think this is the right approach. To cite from Jorgen's
initial post which started this whole thread:

"The usual way to define a project is via the "project root", a
directory so that all files under that directory are considered part of
"the project"."

As he also stresses, this is *not* a complex problem to solve, quite the

Therefore, I don't think it is necessary or even desirable to rewrite
the whole EDE project autodetection into a class-less version, which
then by all means tries to delay loading the "real" EDE as long as
possible. It is not necessary that an 'emacs -Q' can detect all kinds of
projects from Linux kernel trees to the Emacs source. If people need
this, they should just put 'global-ede-mode' in their init file (which
takes about 0.1 seconds on my machine) and use the full-fledged EDE.

To be plain, I agree. What Jorgen described is not the EDE project loader. Here's the deal though. EDE's project loader was once what Jorgen described, without all the classes and stuff. It just detected the project, found the root, and moved on.

Different projects need different features though, and things evolved. If a simple project system is put into Emacs core, it will satisfy the primary use case. Then over time the case+1 will evolve it until it is just as messy as the EDE one.

Case: simple.el is 6000+ lines of code. Everything from set-variable (pretty simple) to compose-mail-other-frame (what ??).

If this project concept is created as a simple thing, that's fine, but EDE won't be able to use it, though it could contribute. If that's the overall story where simple uses need the simple project, and EDE is used when you need more, that seems like a fine compromise, but it won't simplify the plethora of project projects. Of course, that's a good thing too.


reply via email to

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