The Future of Emacs

An anonymous reader writes "If you've not heard much about Emacs development in recent years, you might be surprised to find that it is has been very active. Emacs 22 will have many new features such as support for Mac OS X and Cygwin; mouse wheel support and many new modes and packages. It can also be built with Gtk+ widgets and supports drag and drop for X. The NEWS file details all the changes. Although its very stable, don't expect to see it released any time shortly because according to RMS, the Emacs developers haven't been fixing bugs quickly enough. Those who have followed Emacs for long enough might see a different pattern."

Comments

Times are changeing

[unoengborg]

Even though emacs is a very good editor and development platform that for a long time have filled the purpose of being a swiss army knife for the software developer, I think its days of glory are over.

Sure there will be emacs for many years to come, but I guess that Eclipse will more and more play that role for the generation of developers that grew up with graphical user interfaces. More and more programming languages gets supported by Eclipse, and the support of the existing ones seam to get better and better, and the community around it are getting stronger and stronger.

Even so, its nice to see that old goodies like emacs are still supported and continue to evolve.

Re:Times are changeing

[CyricZ]

I know a number of developers who develop on older hardware. They do that in order to produce software that runs very well on more modern hardware.

Now, they're not using hardware that's all that outdated. We're talking 400-500 MHz Intel or AMD based systems. They're still quite usable as development systems. That is, of course, unless you want to use Eclipse.

I was talking to one such developer who said he used EMACS for his Java development just because it ran far better on his system than Eclipse did. While Eclipse may be a good platform for some, it still does lack in the area of performance and the efficient use of resources.

My favorite Interview question

[dptalia]

was always "vi or emacs?" Since I was interviewing Unix developers, the answer could tell me a lot about them. The people with blank looks who didn't even know you were talking about editor were never asked back.

Re:Emacs OS on Windows OS?

[starseeker]

Frighteningly enough, that might actually be possible. If you were to port Emacs to Movitz Emacs could become an operating system in actuality rather than as a joke!

http://common-lisp.net/project/movitz/

Re:Emacs vs Eclipse: A losing battle

[kzinti]

I've used Emacs for fifteen years, and XEmacs almost as long. I have code (ps-print) in the baseline versions of both. I love Emacs because it made me productive like no other editor did. There are two factors in this equation:

First, I can use Emacs without taking my hands from the keyboard, ever. I can compile, debug, run a shell - you name it, I can do it without having to reach for the mouse.

Second, it is customizable in the extreme. Everything from key bindings to highlighting is driven by Elisp and regular expressions. Don't like the way something works? You can quickly and easily change it by rebinding a lisp function; most importantly, you can make these mods on the fly, without having to run a separate compile step, without having to restart the editor.

That said, I'm impressed with Eclipse. It has some amazingly good features in it; I particularly like the way I can highlight any variable, and instantly see its declaration, inheritance chain, implementing class, etc. We have some of those things, sorta-kinda, in Emacs with tags, but they're not as smooth and slick as Eclipse.

Eclipse has some weak points too. It suffers from Visual Studio envy. Its syntax highlighting is inflexible. Everything about Eclipse is too mouse-oriented - I have to reach for the mouse WAAAY too often for my liking. Emacs-ish bindings are available, but I find them more trouble than they're worth. (I forget why at the moment; I tried the Emacs bindings some months ago, and ended up switching back.)

What I'd like to see is an editor that combines the best of Emacs and Eclipse. You'd never have to take your hands from the keyboard. You'd get the attractive UI of Eclipse without the Visual envy. You'd get an editor that makes you more productive and happy than any other.

(Is something like this dream in Emacs's future? I haven't read TFA, but I rather doubt it.)

Re:Why emacs? Because it's greast

[ScottForbes]

I think it was Eric Raymond who said that all the time that went into snazzy interfaces and GUI support in other programs was spent on editing text in emacs.

You're thinking of Neal Stephenson:

I use emacs, which might be thought of as a thermonuclear word processor. It was created by Richard Stallman; enough said. It is written in Lisp, which is the only computer language that is beautiful. It is colossal, and yet it only edits straight ASCII text files, which is to say, no fonts, no boldface, no underlining. In other words, the engineer-hours that, in the case of Microsoft Word, were devoted to features like mail merge, and the ability to embed feature-length motion pictures in corporate memoranda, were, in the case of emacs, focused with maniacal intensity on the deceptively simple-seeming problem of editing text. If you are a professional writer--i.e., if someone else is getting paid to worry about how your words are formatted and printed--emacs outshines all other editing software in approximately the same way that the noonday sun does the stars. It is not just bigger and brighter; it simply makes everything else vanish.

Emacs is nice, but conceptually dated...

[Anonymous Coward]

I should start off by saying that up until very recently, Emacs has been my main editor. I work on Mac OS X and Linux primarily, and have used Emacs for quite some time. Emacs has worked on OS X for awhile already (either under the Carbon variants that exist, or via X, or via the terminal), so in that regard the article is somewhat misleading.

What I like most about Emacs is that it has the best support for non-mainstream programming languages of any editor, ever. Period. I program in more than a dozen languages (C, C++, Java, Haskell, OCaml, SML, AliceML, Oz, Erlang, Scala, Scheme, Common LISP, Python, Perl, Ruby, APL, etc.), and many of those languages either have no support in other editors, or very poor support if they do. Emacs is the only editor that has at least *decent* support for all of them, and in a way that allows me to maintain a fairly similar style of usage across different languages. In other words, I get to keep my basic functionality and editor customizations relatively the straightforward and things just work pretty well no matter what task I am currently doing. On top of that, extending Emacs functionality to make certain tasks easier is pretty simple, even if you don't know much in the way of elisp. Most of the time, you can simply dig up a snippet of functionality off emacswiki.org. But adding stuff yourself isn't difficult, and the ability to evaluate elisp code inside of emacs itself speeds up the process of writing more complex functionality.

However, it's not all roses. Despite the power of emacs, the reality is that emacs is arcane and outdated as hell. The ugliest manifestations of this arrive in a few different ways:

1) One of them is the ad-hoc way in which emacs is customizable. Emacs basically just runs elisp scripts at run time, and whatever sort of state changing computations that are contained in those scripts reflect themselves in the editor you are eventually presented with. This is a fine idea on a small scale. On a large scale, it's bad. For one thing, it makes extending the editor in specific fashions, with complex features, much more difficult to do in a maintainable way. Essentially, there's little in the way of structure to help maintain conceptual integrity here. It's easy for things to break when you start to combine complex functionality from different pieces of code (usually manifested as modes or something similar) in ways not forseen by their respective authors beforehand. The other end of this, which falls in line with the maintainability problem, is the fact that this approach makes code reuse more difficult. Extensions to the editor in the form of elisp scripts are usually a one-off affair, and are not typically made to be particularly modular. You see the result of this in major-modes which largely accomplish the same tasks, but never share any of the same code. This is common not only in the modes for different programming languages (say they might all support a REPL, but in a slightly different way), but also with modes for other purposes.

2) Unicode support. Emacs is getting much better here in more recent times, but it's far from perfect. Unicode support is difficult to setup on Emacs in a way that is easy to use and works predictably. I have had more experience here on Mac OS X with emacs, so admittedly it's possible that the situation isn't as bad on other platforms. However, true, well integrated Unicode has been late in coming to Emacs because of the legacy of design in the way Emacs has traditionally handled text manipulation and fonts.

3) Display. Emacs text display is starting to show its age. I don't pretend to understand exactly how text display and font handling works in Emacs, but I understand that it is based on legacy designs. Manipulation of the display in text through emacs, with stuff like region highlighting or font locking, is nowhere near as flexible as what is possible in text views for editors in more modern frameworks that follow a design more akin to presentation through styles (

It's more personal than that

[metamatic]

RMS hated Lucid. Really, really hated Lucid. He saw it as a commercial vampire sucking the life out of the MIT AI Lab. Google around and you'll find his essays on the subject.

When Lucid came to him with Emacs changes, it must have been kinda like if Microsoft started submitting multi-megabyte patch sets for the Linux kernel.