Re: A unified project root interface

[David Engster <deng@randomsample.de>]

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.

> Instead, probably another small list left as a buffer-local variable
> that can be tracked.  I imagine it would hold the root of the project,
> and some misc :key describing the nature of the matched project.  That
> would be used instead of ede-object for quick project detection.

[...]

> On the flip side, perhaps this is an opportunity to simplify.  There
> is a bunch of historical baggage in the loader.  I'll bet there are
> some options that could be fixed/removed, simplifying the whole thing.
>
> Anyway, the key is that the autoloader could be recycled into
> something EIEIO free, and a simple hook would give EDE what it needs
> to keep going, without it's current custom autoloader, and it might be
> possible to keep old registration fcns working in the process.

I'm wondering: what is the advantage of having this class-less EDE
autoloader, compared to a new, simple package which is able to detect
simple projects and which can be overridden by EDE?

My problem is not that I don't think this couldn't work. I'm pretty sure
it would. However, it sounds like way too much work for something which
should be really simple, and which has not much benefit for EDE as a
framework; in fact, I wonder if it doesn't even raise its complexity.

-David