Thread: [CEDET-devel] Advancing CEDET
Brought to you by:
zappo
From: Alastair R. <ala...@gi...> - 2016-06-12 15:37:49
|
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. 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. 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. 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. 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. 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. Thanks, |
From: Eric L. <er...@si...> - 2016-06-15 00:27:01
|
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 |