Take the 2-minute tour ×

I'm finishing my master degree course in CS and I've almost become addicted to Emacs. I've used it to write in C, Latex, Java, JSP,XML, CommonLisp, Ada and other languages no other editor supported, like AMPL.

I'd like to improve the packages I've been using the most or create new ones, but, in practice, I find that the implementation of Emacs leaves a lot to be desired. There are a lot of poorly-featured/poorly-maintained packages with either overlapping functionalities or obscure incompatibilities, and Elisp just seems to foster the situation by lacking the common features modern lisps have.

In contrast Eclipse and Netbeans are actively improved and it does seem they can be effective for non-mainstream languages. I tried Hibachi for Ada in Eclipse and it worked well, there's CUPS for Lisp in Eclipse and LambdaBeans built using NetBeans components. On the other hand those plugins seem to be less active than their Emacs' counterparts, for example Hibachi was archived last year.

What's your opinion on this? Which editor should I write extension for?

EDIT: To answer Larry Coleman (see comment below):

  1. I like Emacs as a user because it is efficient both for me and the computer I'm using. It's fast and the textual interface (i.e. minibuffer) allows for quick interaction. It's solid and packages are usually small and easy to manage. If I need to correct or remove something I usually just have to change a row in my .emacs or an elisp file, or delete a directory. Eclipse plugins rely on a more complicated process that screwed my Eclipse configuration a couple of times, forcing me to do a clean reinstall. Emacs works as long as I use the basic packages. If I need something more complicated the situation gets pretty hairy.

    As a "power user" I think that the best I can hope for is to write a severely crippled version of the extensions I'd actually like to have; in other words, that it's not worth the trouble.

  2. I'd like to write extensions for the things I'd like to have automated in Emacs, for example project support with automated tag-table update on file writing. There are a few projects on this that lack integration, documentation, extensibility and so forth. The best one is probably CEDET, for which I believe the Greenspun's 10th rule can be applied.

EDIT: To comment Larry Coleman's answer

I'm pretty sure I can pick elisp programming but the extensions I have in mind don't exist yet despite their relative simplicity and the effort more knowledgeable people poured into related projects.This makes me wonder whether it is so because of the way emacs is developed, i.e. people tend to write their own little extensions without coordination, or its implementation, its extension language not being able to keep up with the growing complexity.

share|improve this question

closed as primarily opinion-based by MichaelT, Alex Feinman, Kilian Foth, World Engineer Mar 26 at 19:18


Emacs is a very special editor, no matter what you move to, it'll have missing features that annoy you indefinitely. –  Orbling Jan 22 '11 at 17:47
The best answer to this question will depend on two other questions: (1) What do you like about Emacs? and (2) Why do you want to write extensions? –  Larry Coleman Jan 23 '11 at 21:01
add comment

5 Answers

IMHO, Emacs is the best option.

Writing an add-in for a real IDE will absolutely be easier to program and maintain, the problem is that the code is then trapped in that IDE. This forces you to pick the one IDE which will host your add-in. Which in turn, forces you to pick a host operating system. And programming language(s) for which people will use your add-in. And so on.

Emacs add-ins, as horrible as writing them as it is, allows your add-in to work on whichever platform you can get Emacs to run. (Which last time I checked was everything.) This inherent portability of elisp is what has contributed to Emac's longevity over the years.

Another way to think of this problem is compiles. You don't want to have a one-to-one mapping between source languages and output languages. It's much better to have an IR so you can have your compiler produce x86, x64, and other target outputs.

You would think that we would write IDE tools in the same way. However, most IDEs only support one to two languages well. (Since most all built-in tools are hard wired for specific languages.)

Sorry to go off on a mini-rant.

share|improve this answer
Thanks for the reply, but I find your comparison flawed: (I) Elisp code is trapped in Emacs and I have never heard of elisp code reuse from outside Emacs. NetBeans(NB) and Eclipse(Ecl) instead do allow for that, see LambdaBean (II) NB and Ecl are "multiplatform", they run on any system that supports java, e.g. Win,Unix and Mac. Emacs does too, but it seems to be integreated less in Windows than in Unix, for example it hasn't the faintest idea of where your home directory is. (III) Eclipse and NetBeans do support multiple languages via plugins. –  Andrea Jan 22 '11 at 18:20
NetBeans, for example, supports at least Java, JavaScript, PHP, Python, Ruby, Groovy, C, C++, Scala, and Clojure. It runs everywhere where a JVM is installed, including Windows, Mac OS, Linux, and Solaris. That's enough for me, at least :-) –  Joonas Pulakka Jan 22 '11 at 19:47
add comment

I'm not sure that anyone really likes elisp. There were rumblings a few years ago about replacing it with Guile, but nothing really came out of it. The main obstacle to re-writing Emacs using a better Lisp is the millions of lines of existing elisp code. This code would either have to be re-written, or the elisp replacement would need a compatibility layer. Either way, the cost/benefit ratio doesn't support the switch. So for better or worse, you'll have to live with elisp (though I've heard there's a CL extension to it). And don't worry about your dissatisfactions with Emacs and elisp; it's quite normal.a peculiarity of the Lisp world that the most substantial complaints come from the people who know it best; the only people complaining about parentheses are newcomers and people who don't use Lisp.

That said, you'd be best served by living with the ugliness of Emacs and elisp and writing your extensions there. Your extensions will become more powerful as you become more familiar with elisp. At the same time, you'll be able to keep the efficiency of Emacs that you're used to.

share|improve this answer
add comment

You should write extensions for the editor you actually use. For Java development the benefits of using a modern Java IDE is so great that unless you have a really good reason to, you should use an IDE instead of an editor. Examples are globally changing a method of a signature or choosing which implementation of an interface to navigate to. Try using JDEE for a while and then compare with e.g. Eclipse, Netbeans or IntelliJ.

One of the benefits of Emacs is that it is very easy to provide hooks and override functions which compares very well to plugins and configuration in e.g. Eclipse. Unfortunately Emacs is below critical mass in terms of developer resources. This would mean that your extensions would not be able to leverage the work of others, and you would have to do all the work yourself. In most employment situations that would not be an option, and they would most likely ask you why you just cannot use an IDE like everybody else and get real work done?

Also, you will most likely be dependent on your plugins which in turn mean that you may have problems working in teams which do not use your plugins. I've found that only using standard plugins make team work much easier.

So, write extensions for the IDE you use if you need to, but be careful not to introduce limiting dependencies.

share|improve this answer
add comment

Most IDEs have emacs key-binding mapping. Not as good but better then nothing.

share|improve this answer
add comment

I think it depends on exactly what extensions you want to write. If you need features that just don't exist in emacs but do exist other places, then go where the features are I would say. That said, you might be surprised by what does and doesn't exist in Emacs. Things have gotten much easier since ELPA, but finding Emacs plugins is still non-trivial IMHO.

I have seen a lot of movement in Emacs recently. If you really need a package that doesn't exist, start a public project (github has a lot of traction emacs package wise), advertise it a bit, and if other people want the same extension, you'll have pull requests in no time. You might also consider using a service like Freedom Sponsors to "request" a feature if it's beyond your skill level. People do tend to scratch their own it itch, since they're not getting paid for it, but there are lots of people who are willing to help here and there on a project that they wouldn't maintain or write themselves.

share|improve this answer
add comment
