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

On 03/21/2013 12:32 PM, David Engster wrote:
Eric M. Ludlam writes:
W>  On 03/20/2013 01:47 PM, Stefan Monnier wrote:
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 email, and browsing in eieio.el in the CEDET repository gave me
an a-ha moment.  I think I know how to "split" eieio such that the
eval-and-compile elements are fixed, and have a much nicer eieio.el in
the process.  My initial experiments show I'm on the right track.

David, is there something that needs merging from Emacs to CEDET I
need to worry about before making massive structural changes in EIEIO?

No, it's all already merged to upstream, including the renames by

Great!  Thanks.

If the goal is to use EDE's detection scheme and data, but not load
EDE project classes, then we are all set already since the EDE project
classes are not directly involved in detecting the projects.  If the
goal is to not use EIEIO at all, then we'd end up just using a plist
other random data structure instead of using EIEIO to do it.  This
wouldn't be a big deal because AFAIK, these classes aren't subclassed,
so impact would be small.

Let's talk examples, then. Say we have

  (ede-project-autoload "vcs-root"
                       :name "VCS ROOT"
                       :file 'vcs-root
                       :proj-file 'ede-check-for-vcs-dirs
                       :proj-root 'ede-vcs-root-dir
                       :proj-root-dirmatch "NONE"
                       :class-sym 'ede-vcs-root-project
                       :load-type 'ede-vcs-root-load
                       :new-p nil
                       :safe-p t)

So from that we'd take the list of slots, which is practically a plist,
and would write something akin to ede-dir-to-projectfile, but using
plist-get/set instead of oref/oset?

Yes, basically. Seems odd to swap one data type form for another, but there it is. Since the class name is used as a function, no code using it will need to change. Perhaps.

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.

Once that is working, I had originally thought we could use the ede-project-placeholder as a starting point since it was designed to be swapped out for a real project later, but that is still an EIEIO class.

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. I think it would also need a couple new hooks, including ede-new-project-detected-hook. EDE would use that to actually load a project instead of doing so directly from the auto-loader.

Another option is to hand-craft an EIEIO object vector. They are all just vectors, so if we had an EIEIO class that had a small number of slots (smaller than the existing placeholder object) it could be created by hand with (vector ... ) and used to track projects. Once EIEIO was loaded, more complex code could just keep using it, but as an object. I wouldn't do that if there were more than 2 or 3 slots in it though. As code changed, the indices might change, and maintenance would be a pain. As for a transition strategy though, it might make things easier.

As for ede-check-for-vcs-dirs, it would need to provide data to the auto-loader that doesn't need to be called to detect the project. There is a bit of logic that says "If the :file isn't loaded yet, try this other thing". That way if it is loaded, it can use one of the handy functions which often have caches of their own for detection and makes things faster.

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.


reply via email to

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