Re: Advancing CEDET

On 06/12/2016 11:24 AM, Alastair Rankine wrote:
> Hi all,
>
> I have some ideas and suggestions for advancing CEDET. Some of these
> have probably been brought up before, if so I apologise for the
> duplication. However there may be some relatively simple steps we can
> take to make CEDET more accesible, and hence more widely used.
>
> My impression is that there is still some reluctance to embrace CEDET,
> as it has something of a reputation for being difficult to set up and
> configure. Whether this reputation is justified or not, I think there
> are things we can do to make CEDET more successful.

Thanks for the idea list Alastair!

I think this is indeed true.  CEDET developed slowly over many years.  A 
side effect is that it is a bit eclectic, and has some bad reviews of 
old versions out there.

> 1. Packaging
>
> I think it would be good for CEDET to embrace packaging infrastructure
> such as MELPA, in order to provide updates prior to official GNU Emacs
> releases. I'm not even sure how the CEDET code migrates into Emacs, or
> what the next version is going to contain. However I think that
> packaging via MELPA would make this irrelevant, and significantly
> lowers the barrier to installation.

David Engster used to handle cross merging between the CEDET repository 
and Emacs, but that became more difficult over time.  Once Emacs did 
some major refactoring to eieio, our ability to support older and newer 
Emacsen at the same time broke down.

The next major step is to do one final merge from CEDET repository up to 
Emacs, or something that gets the two systems in parity.  All the pieces 
of CEDET that are not part of Emacs would indeed work well in some other 
packaging scheme.

> 2. Modern project hosting
>
> I can't be the only one who views sourceforge's increasingly dated
> website as a barrier to attracting contributions to the CEDET project.
> Github (or equivalent) would provide key features which we currently
> lack such as a wiki, issue tracking, etc. Perhaps these features are
> available with sourceforge, but regardless the user experience is far
> better on Github.

It was proposed to just use Emacs' repository (ie - don't have a 
separate repository with cross merging needed.) which I am ok with. 
I've been using sourceforge for a long time and it is familiar, but in 
the end I mostly just use the VCS which doesn't change much.

> 3. Online documentation
>
> Sites such as readthedocs.org provide a great place to host online
> documentation in a way which is navigable and usable. I think the CEDET
> project has great documentation in general - but publishing it online
> would make it far more accessible to people.

I am not familiar with that system, but sounds interesting.  I tried 
reading Emacs' doc (which might be there?) but couldn't figure it out in 
30 seconds or less due to all the versioning hoops it asked me about.

> 4. Third-party package integration
>
> In contributing to ede/compdb I have added some optional support for
> widely used third-party packages such as Projectile, Company, etc. In
> order to do this without introducing dependencies on the core CEDET
> code, I think it may be possible to create non-core "glue" packages,
> which provide the integration, or at least interop, with popular and
> relevant third-party packages. EDE and Projectile are the main suspects
> here - but there are others.

The idea of creating mini packages to glue external tools into CEDET 
workflows was always a goal.  To keep the unit together, things tended 
to integrate into CEDET so users could find them.

With CEDET in Emacs, and many of the interfaces have been stable for a 
long time, having a way allow such packages to just depend on Emacs 
would be reasonable.

> I am willing to help out where I can to enable some of these changes,
> provided there is a willingness to do so. Comments appreciated.

Help is what is needed most.  Resolving the last merge up into Emacs, 
and setting up guidelines for continued development is what is most 
needed.  I'm not too picky as long as I can keep submitting my patches 
and tests somewhere meaningful.

Eric

------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://pubads.g.doubleclick.net/gampad/clk?id=1444514421&iu=/41014381