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.