emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CEDET merge


From: David Engster
Subject: Re: CEDET merge
Date: Sat, 06 Oct 2012 19:29:15 +0200
User-agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.1.50 (gnu/linux)

Stefan Monnier writes:
>> By the way, could you or Eric kindly write up a NEWS entry briefly
>> describing the major changes to CEDET since CEDET-1.0 / Emacs-24.2?
>
> I'm also interested to hear about how close we are to having Emacs's
> CEDET and the upstream CEDET actually in sync (and kept in sync via
> a semi-automatic process).

Regarding the files which are both in Emacs and in CEDET: those are
pretty much in sync now except for some compatibility code we have to
keep for Emacs 23.1.. We also have some 'defadvice' hacks which we
obviously cannot merge. For getting rid of the defadvices, some changes
in Emacs core packages are needed, but I didn't have time to do that
before the freeze (for example, getting proper help buffers for EIEIO
classes and methods is pretty high on my TODO list).

There are still some packages which are only in CEDET upstream for
several reasons: They're either pretty new and not well tested, or are
in our 'contrib' directory and don't have proper papers, or because they
are a bit obscure (sorry Eric ;-) ) and well separated and hence would
better fit into ELPA. For example, I think Cogre (for generating UML
graphs) would be a good candidate for an ELPA package.

Also, we now have two additional branches in CEDET for doing merges to
and from Emacs; those are in fact "real" branches, meaning they have a
common history, and after the first batch of humongous merges they work
pretty painless now. The real work is in doing the 'diff|patch' thingy
from Emacs to CEDET, but I've written a package for that which makes
that fairly fast. All this should make it possible for me to do regular
merges from now on, like the Gnus/Org people do.

In addition, we are planning to move development of certain packages
completely to Emacs trunk. We already did that for Speedbar; the next
candidates are EIEIO and mode-local.

-David



reply via email to

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