One of the notable new features of emacs 23.2 was the inclusion of CEDET. CEDET adds IDE-type functionality to emacs, and one only needs to read the responses to the 100th post to see the great interest in that.
The man behind CEDET is Eric Ludlam (EML), a long-time Emacs user and developer. He kindly answered the many questions we had for him. Thanks, Eric!
djcb: Eric, could you tell us a little bit about yourself? And about that fantastic hobby of yours, building siege engines?EML: I manage a software engineering team at the MathWorks. The MathWorks are the creators of Matlab. In my spare time I maintain CEDET, the Matlab support for Emacs, and build replicas of ancient siege engines.
I've been building catapults of various types for use at the World Championship Punkin' Chunk since 1998. My team started with a traction trebuchet, then a HCW Trebuchet, then moved to Human Powered Centripetal, and finally to the torsion division with MistaBallista. As far as I know, Mista Ballista is the worlds largest farthest throwing currently functional ballista.
Most recently, I got to help demolish a building where I work by shooting stuff at it, which was a lot of fun.
djcb: How did you get involved with Emacs? Do you spend a lot of time with it?
EML: I've been hacking Emacs since version 18.54 on Ultrix because the alternative
was vi. My first post (and thus contribution to Emacs) was to
gnu.emacs.sources on June 6, 1992. I've used Emacs to work on C/C++ code for
many years which inspired all the various parts of CEDET, but these days I
don't get much coding time.
My work with Emacs and CEDET is seasonal currently. The summers are usually busy with family activities, and my falls are busy getting the catapult ready, so CEDET work usually happens in the winter.
djcb: Can you tell us a bit about the background of CEDET?EML: I started with some really basic editors and eventually with LSE (Language Sensitive Editor) on VMS. LSE was pretty cool. When I switched OSes to Ultrix and was forced to use Emacs, and discovered you could script it, I was hooked. My first big Emacs hack was etalk, an implementation of Unix talk in Emacs.
In one of the Emacs related newsgroups, a spoof story floated around about how
Emacs became sentient, and started writing code for Richard [Stallman] instead
of the other way around. Since then I've always wanted to get Emacs to start
writing my code for me. I wrote cparse.el, a regexp nightmare that could
parse almost any C file into a sequence of highly detailed tags. The tags
could be used to then generate code, and I had a cool comment writing utility,
automatic prototype generation, and some navigation features. On the whole it
failed for many reasons.
The concept, however, continued. CParse became the basic idea behind what is now the Semantic package in CEDET, though none of the old stuff remains beyond some echos in some SRecode utilities.
My end goal is to provide round-trip code management in Emacs. Emacs needs to be able to read your code, allow you to perform transformations in the code in an abstract way, and then write new code for you. Everything in CEDET is building toward that goal. It is taking a long time, and you can see it starting to take shape. Semantic can parse the code, COGRE can manipulate UML diagrams representing your code, and you can export diagrams into code through SRecode. Unfortunately this isn't a round-trip solution as the generated code currently should not replace existing hand-written code.
Can you tell us a bit about the CEDET-project?EML: I maintain CEDET and field questions on the mailing list. There are several contributors who either own some tool in the "contrib" area, fix bugs, answer questions or apply patches for new features. There has always been someone to pick up the slack when I'm busy elsewhere, and I've greatly appreciated that.
The easiest (and most common) way to contribute code to CEDET is to provide support for some new language, or to create a language agnostic tool using the CEDET APIs. As with Emacs, you need to be able to assign copyright to the FSF to contribute to CEDET's core, but new language support or utilities can have a home in the contrib area as well.
djcb: CEDET is part of Emacs since 23.2. Can you tell us a bit about how that happened?EML: I've been providing assignments for the parts of CEDET since 1996 or so. For Emacs 23.1, CEDET was at a stable and useful enough state that Chong Yidong was willing to do the work to integrate it into Emacs. My ability to get a legal release for CEDET in time for Emacs 23.1 failed, so it went into 23.2 instead. It is my understanding that CEDET's smart completion engine reached a performance and reliability point that made it desirable to have in Emacs.
Emacs currently includes the parts of CEDET needed to make EDE, the project management system, Semantic and it's user tools, and SRecode all work from a user perspective. Emacs lacks the Semantic development environment, needed for writing new language support, and COGRE, the UML diagram editing tool.
djcb: Are there plans to include those parts as well?Yes. It is important for users with a stock Emacs to develop new languages using the missing Semantic development tools. I don't know if COGRE will ever go in, though I expect that this will be done via the new package management system [elpa].
djcb: Did you ever try IDEs such as Eclipse? How do you think CEDET stacks up against such programs?EML: I have used Visual Studio more than Eclipse, and certainly watched demos on how these and other tools work.
These tools win over CEDET's features in that they usually integrate directly with the compiler, VM or whatever, and have very good completion engines and UIs that you can interact with.
CEDET wins in that you don't need a compiler, or even code that can compile for it to work and start providing useful completions. It can infer an awful lot from a project.
CEDET's language support structure is thus simple in comparison, and CEDET supports many more languages as a side effect. It also wins because it is in Emacs, and I've done my best to try and match the "Emacs Way". For an Emacs user, this is intuitive, but can appear quirky to outsiders.
djcb: What about other development tools for in emacs?EML: There are a lot of language specific solutions like GCCSense, slime, JDEE, and others out there. These projects are great in that they take a language, and push it to the edge of what you can do, and the users generally love that stuff. When someone wants to do the same thing, like when CSDE started for C#, and it tried to copy JDEE, it was just that, a copy that didn't quite make it.
It is my hope that CEDET will become the target of choice for users who want
to make their language support in Emacs the best. They will save a lot of
time doing so as well. The same infrastructure for integrating in external
tools can be used to get improved results out of CEDET, but CEDET will handle
converting that into a representation that would then allow any tool built on
CEDET to work. This is the same model that worked well for comint.el, and
gud.el.
Yasnippet is a bit different in the way it "competes" with SRecode. My first implementation of SRecode tried recycling tempo templates, but I couldn't get it to work. In fact all the template systems I investigated fell short of what I was trying to do, so I had to roll my own, and ended up using a variant of the Google template format.
The key difference is that the goal was for SRecode to provide a series of
base templates for code generation. A tool writer would then write some tool
to generate code. A user would then use the tool, and say "This is great, how
do I change where the { goes?"
The answer is to override the template with that detail in it without interfering with the system templates. That only works if the templates are sufficiently granular that the changed template can be simple. Template reuse needs to be high so that if your company formats your methods as:
int mymethod() { implementme() };
instead of
int mymethod() { }
that one template change will allow this to happen for all code generated from every tool.
Thus, the audience for yasnippet and SRecode is quite different. Of course you could do yasnippet like things with SRecode if someone took the time to improve the field-editing feature in SRecode, but that has not been my focus.
djcb: Do you follow the overall Emacs development process? Are there things you would like to see changed/improved?
EML: I watch the emacs-devel mailing list, mainly to see if anything
related to CEDET goes by that I can help with, or what the latest cool
feature might be. My first contribution of Speedbar to Emacs in Emacs 20
helped drive some features related to overlines, boxes, and other face
attributes that appeared in Emacs 21.
In the future, once CEDET and Emacs cross merge techniques are hashed out, I
would expect some key parts that need performance improvements might move into
C. Another part of CEDET that I'd love to see become bound closer to Emacs is
mode-local.el. It tries to simulate mode-local variables and mode-local
functions. This is critical in a complex system like CEDET that needs to
provide a language support author with fine grained control. There are good
reasons not to make what is currently implemented "the Emacs way", but it
would be nice to resolve those and enable mode authors a with a more powerful
way to customize the user experience.
EML: Here is the short list:
- Improve Emacs/CEDET cross merging
- Offload tag storage to an external process - needed for scalability
- Design/define a "CEDET mode" as a way of simplifying the confusing array of distinct tools and modes that make up CEDET now.
- Finish the smart-context menu project
- Resolve the "code replacement" problem of parsing a block of code, transforming it, and re-creating that code in place reliably.
EML: Supporting new "stuff" in CEDET is one big win. Stuff can be:
- New project types under EDE to ease transition from something like Visual Studio to Emacs.
- Language support, such as parsers, or mode overrides. Finding ways to take existing cool tools, like JDE's beanshell, or slime's inferior lisp process and allowing it to do work for CEDET is another big win.
- Templates for code generation in new languages.
Tool writing would also be good. JDEE's author Paul Kinnucan converted many bits of JDEE to CEDET and co-designed many of CEDET's parts along the way, such as semanticdb, and that was a huge help. ECB's current maintainer Klaus has also had a big impact on the way concepts are abstracted to a tool that depends on CEDET.
Naturally, joining the mailing list and fixing reported bugs and improving the doc is also a huge help, but not as exciting as writing new code. :)
djcb: Finally, many people want to start using CEDET, but it seems they have a bit of trouble to get started. Do you have any recommendations for them?
EML: Start with the cedet.info file which has many of the common setup
configurations in it. If you run into something not explained well or at
all, be sure to join the mailing list and be specific about how that doc
failed. Very few questions on the mailing list refer to the doc, so the doc
is rarely improved in a way that can help others.
Another good starting point is Alex Ott's article A Gentle Introduction to CEDET, which is very helpful.
Thanks a lot for your time, Eric! Wishing you a lot of success with CEDET and all your other projects!