Advancing CEDET
Alastair Rankine <[email protected]> Sun, 12 Jun 2016 11:24:42 -0400
| Newsgroups | gmane.emacs.cedet |
|---|---|
| Message-ID | <[email protected]> |
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, ------------------------------------------------------------------------------ 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. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e