> It's not like packages communicate with Emacs over a well
> defined RESTful interface. In other words: CEDET and Gnus are not
> loosely coupled, quite the opposite: they are extremely dependend on
> many obscure Emacs internals (not sure about Org).
Shouldn't we be trying to avoid this situation
>
> DE> This is a misunderstanding. I said I wanted to move support for certain
> DE> languages and project types into ELPA, not CEDET core. I'm still of the
> DE> opinion that moving it completely to ELPA is a mistake.
>
> It would only be a mistake if other parts of core need to use it. If only
>
>>> they are extremely dependend on
>>> many obscure Emacs internals (not sure about Org).
>>
>> Shouldn't we be trying to avoid this situation? It's sure to come back
>> and bite us in the future. If we continue to develop a package
>> (wherever it ends up being developed) which is so tightly co
>> - Suppose that Emacs 22.0 is the current release and Emacs 22.1 is then
>>released; CEDET is at
>> - we update a registry somewhere indicating that Emacs 22.0 works with
>> and 22.1 works with
>>
>> - When we make updates to CEDET we mark 22.1 as working with
>> but we don't
>> Which CEDET features would we want to use from core?
>
> For one, I'd like to see more major modes come with support for Semantic
> right in the major mode's own definition (rather than have it part of
> CEDET). E.g. for Elisp mode, CC-mode, ...
>
> The idea is to get to the point where Semanti
