Re: A unified project root interface

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> [ Actually, there are various reasons to split EIEIO, one of them would
>> be to try and fix the eval-and-compile mess.  ]
> What do you mean by "splitting EIEIO"? Into what parts?

Sorry, I mostly meant "split eieio.el".  What parts?  Well, that's
a good question.  I think if I knew, I'd have done that already ;-)
Maybe a first split would be "all the code in eieio.el up until the end
of the first big eval-and-compile".
At least, if the aim is to get rid of those nasty eval-and-compile.

> This won't work; you cannot detect whether a file is part of a project
> without the project's definition (which comes in the form of a class, as
> I've already written). It's a chicken/egg thing.

I don't think so.  The first part of the detection is to look for the
tell-tale files (.bzr, .dir-locals, Tupfile, you name it).

The project definitions can setup some side table that can be preloaded
and used by a function that looks for those files.

Some of those files will be frequent enough that we may also want to
preload some additional predicate that checks whether we really need to
load "the rest".


        Stefan