Re: Next Gen JDEE
Stephen Leake <[email protected]> Wed, 15 Jul 2015 02:31:29 -0500
| Newsgroups | gmane.emacs.jdee.devel |
|---|---|
| Message-ID | <[email protected]> |
Paul Landes <[email protected]> writes: > Again, my earlier plans were to create a brand new project and port > over pieces from JDEE. Starting new I think is necessary to start the > ball rolling where as a major refactoring of the existing code base > would be an up hill battle against the mentioned inertia of a large > project. I recently did the same for Emacs Ada mode; the new code is much cleaner and easier to maintain. I prefer to program in Ada; I only use Java for Android projects and FIRST robotics. > - Replace beanshell with clojure I gather clojure is better maintained, and will stay current with any new Java features? In particular, generics? > - Replace semantic with some Java based parser (maybe compiler like > ASM)--however all fly compilation and syntax correction etc happens in > Java. I wrote a new parser for Emacs Ada mode in elisp, and am now attempting to re-implement that in Ada as an emacs dynamic module, for speed reasons (some people have Ada files with over 1000 lines ...).. I did this because the Ada language is more complex than other languages Emacs support, and/or I'm more picky about getting the indentation right for _all_ constructs :). What parser to use depends heavily on how much you care about handling incorrect syntax gracefully (to get parser-dependent stuff right while editing). For Ada, I make no attempt to handle this gracefully currently, but I hope to improve that in the new parser. The parser is used for several things: indentation, navigation, completion, and possibly highlighting. They all add different requirements, but they all push towards implementing a complete parser. The Semantic parser is LALR. The Emacs Ada mode parser (called 'wisi'; http://stephe-leake.org/emacs/wisi/wisi.html) is generalized LALR; it can handle conflicts. The language that wisi parses is described in a bison-like grammar file, so it could be used for Java. Using a generalized LALR parser means it is much easier to write the grammar in a way that is clear and understandable. Interfacing an external parser to Emacs is currently not easy. Operating as a separate process communicating thru pipes is slow, partly because the Emacs pipe operations are not designed for large amounts of data, so they have built-in delays. There is now an experimental dynamic module interface, allowing external code to link to Emacs as a dynamic library, but it's on a branch, and probably won't be in Emacs 25. > - Entire project becomes an Emacs plugin There are at least three styles of Emacs plugin: - Gnu ELPA package - random elisp files (current status) - dynamic library with elisp files (very experimental) So I'm not clear what you mean here. It should be fairly straight-forward to clean up the current code for emacs master and package it as a Gnu ELPA package. > - Move to a plugin approach so each add on is a separately maintained > Emacs plugin. If you can identify clear candidates for plugins in the current code, then moving to a plugin architecture for a rewrite makes sense. Emacs Ada mode makes an attempt to support different backends for indentation, compiling, and navigating (cross-reference). It's fairly clean. It would be cleaner with eieio classes. > If someone wants to resurrect jde-debug from JDEE into the new > version, then that person creates a new Emacs plugin that fits in some > next gen JDEE plugin architecture. If jde-debug is a Java/JVM backend for Emacs gud, then gud already has a plugin architecture for its backends; it has very little to do with the main jde mode. For example, there is no code related to gud in Emacs Ada mode. > This gets rid of some bloat ini the core next gen JDEE. Perhaps it just needs to be split into separate Gnu ELPA projects. > - Who has the time and initiative to help out (I can't do it all > myself with current time constraints) I'd like to work on getting the current code working with emacs master, each depending on jde-core. > - Should the project have a new name or carry the same name? My > feeling was start a brand new project for the purpose of name space > and maybe create more "buzz" as a "new" Emacs java development > library. Keep jdee, just do a major version bump. -- -- Stephe ------------------------------------------------------------------------------ Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/