> By default Emacs is passable Elisp IDE and nothing more, really. To my eye, that's a bit of an overstatement. I used a mostly unconfigured Emacs for years to

> By default Emacs is passable Elisp IDE and nothing more, really. To my eye, that's a bit of an overstatement. I used a mostly unconfigured Emacs for years to write C, Lisp, and Scheme and found it to be quite suitable. My approach to customizing it has largely been to identify pain points and then work to find low impact ways of working around them. At first, it was relatively simple things like binding filename extensions to modes and tweaking buffer coloring. Later on, I realized that I wasn't using any of the GUI widgets (toolbar, menubar, and scrollbar) and disabled them entirely. That was shortly followed by an OSX recompile that added a full screen mode, prior to OSX having the feature natively. I've done some larger scale customizations too, but those tend to be shorter lived and focused on specific projects. When I ran more on Windows, I had cygwin enhancements running in Emacs. I'm doing more Oracle these days, so I have SQLPlus mode linked in. I also work with Clojure mode (essential) and js2-mode (nice, but I could live without it). Because I use git, I tried magit mode, found it to be slow and cumbersome, and switched back to the git command line. The two longer-term customizations I've found to be useful are a enhancement to org-mode that I wrote to keep a personal notebook/wiki, and a simple elisp wrapper I wrote around Maven for building Java projects. I wrote these to address specific common use cases in my work flow, and as I find pain points, I try to find cheap and easy ways to file them down. Honestly, I tend to keep the customization code as simple as I can, because I'd really like to spend as much of my time on 'real work' as I can, and the editor is just a means to that end. If you're interested to see what that looks like in Emacs Lisp terms, I've maintain my .emacs here for the last few years. (Prior to github, I just copied the files around, which was as painful as it sounds.) https://github.com/mschaef/.emacs.d https://github.com/mschaef/.emacs.d > Its main strength lies in how easy it is to extend and customize it. Agreed, but for me, the brilliance is that it makes it easy to write small customizations that are still quite powerful. Eclipse is fully extendable in theory, but the barrier to entry is high due to the complexity. While Emacs does support a lot of that kind of 'big' customization, it also makes it easy to gain small point victories with small amounts of code and complexity. Another quick example of this is that about ten years ago I was writing a small unit test library for a scheme system I was developing. I really wanted the ability to jump to the source of the failing tests. Getting this done in Emacs was as simple as modifying the format of the test failure messages to match one of Emacs' compile error message formats. Then, the 'next-error' function just did what it should. It took an hour or two of effort and a half dozen lines of code to make a huge difference in my daily productivity at the time.