Re: A unified project root interface

["Eric M. Ludlam" <eric@siege-engine.com>]

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
> contrary.
>
> 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.

Eric