Monday, April 28, 2008

XEmacs is Dead. Long Live XEmacs!

 "We're going to get lynched, aren't we?" — Phouchg


And you thought I'd given up on controversial blogs. Hah!

Preamble

This must be said: Jamie Zawinski is a hero. A living legend. A major powerhouse programmer who, among his many other accomplishments, wrote the original Netscape Navigator and the original XEmacs. A guy who can use the term "downward funargs" and then glare at you just daring you to ask him to explain it, you cretin. A dude with arguably the best cat-picture blog ever created.

I've never met him, but I've been in awe of his work since 1993-ish, a time when I was still wearing programming diapers and needing them changed about every 3 hours.

Let's see... that would be 15 years ago. I've been slaving away to become a better programmer for fifteen years, and I'm still not as good — nowhere near as good, mind you — as he was then. I still marvel at his work, and his shocking writing style, when I'm grubbing around in the guts of the Emacs-Lisp byte-compiler.

It makes you wonder how many of him there are out there. You know, programmers at that level. He can't be the only one. What do you suppose they're all working on? Or do they all eventually make 25th level and opt for divine ascension?

In any case, I'm sad that I have to write the obit on one of his greater achievements. Sorry, man. Keep up the cat blog.

Forking XEmacs

I have to include a teeny history lesson. Bear with me. It's short.

XEmacs was a fork of the GNU Emacs codebase, created about 17 years ago by a famous-ish startup called Lucid Inc., which, alas, went Tango Uniform circa 1994. As far as I know, their two big software legacies still extant are a Lisp environment now sold by LispWorks, and XEmacs.

I'd also count among their legacies an absolutely outstanding collection of software essays called Patterns of Software, by Lucid's founder, Richard P. Gabriel. I go back and re-read them every year or so. They're that good.

Back when XEmacs was forked, there were some fireworks. Nothing we haven't seen many times before or since. Software as usual. But there was a Great Schism. Nowadays it's more like competing football teams. Tempers have cooled. At least, I think they have.

As for the whole sordid history of the FSF-Emacs/XEmacs schism, you can read about it online. I'm sure it was a difficult decision to make. There are pros and cons to forking a huge open-source project. But I think it was the right decision at the time, just as decomissioning it is the right decision today, seventeen years later.

XEmacs dragged Emacs kicking and screaming into the modern era. Among many other things, XEmacs introduced GUI widgets, inline images, colors in terminal sessions, variable-size fonts, and internationalization. It also brought a host of technical innovations under the hood. And XEmacs has always shipped with a great many more packages than GNU Emacs, making it more of a turnkey solution for new users.

XEmacs was clearly an important force helping to motivate the evolution of GNU Emacs during the mid- to late-1990s. GNU Emacs was always playing catch-up, and the dev team led by RMS (an even more legendary hacker-hero) complained that XEmacs wasn't really playing on a level field. The observation was correct, since XEmacs was using a Bazaar-style development model, and could move faster as a direct consequence.

A lot of people were switching over to XEmacs by the mid-1990s: the fancy widgets and pretty colors attracted GNU Emacs users like moths to a bug-zapper.

Problem was, it could actually zap you.

The downside of the Bazaar

I personally tried to use XEmacs many times over a period of many years. I was jealous of its features.

However, I never managed to use XEmacs for very long, because it crashed a lot. I tried it on every platform I used between ~1996 and 2001, including HP/UX, SunOS, Solaris, Ultrix, Linux, Windows NT and Windows XP. XEmacs would never run for more than about a day under moderate use without crashing.

I've argued previously that one of the most important survival traits of a software system is that it should never reboot. Emacs and XEmacs are at the leading edge of living software systems, but XEmacs has never been able to take advantage of this property because even though it can live virtually forever, it's always tripping and falling down manholes.

Clumsy XEmacs. Clumsy!

I assume its propensity for inopportune heart attacks is a function of several things, including (a) old-school development without unit tests, (b) the need to port it to a gazillion platforms, including many that nobody actually uses, (c) a culture of rapid addition of new features. There are probably other factors as well.

I'm just speculating though. All I know is that it's always been very, very crashy. It doesn't actually matter what the reasons are, since there's no excuse for it.

Interestingly, most XEmacs users I've talked to say they don't notice the crashing. I'm sure this is because it's all relative. XEmacs doesn't crash any more often than Firefox, for instance. Probably less often. When Firefox crashes I make a joke about it and restart it, because the crashing rarely has an impact. It even restores your state properly most of the time, so it's just a minor blip, an almost trivial inconvenience, so long as whatever text field you happen to be editing has an auto-save feature. And most of the good ones do.

XEmacs may crash even less than Eclipse and IntelliJ. Crashing editors usually aren't a big problem. Programmers all learn the hard way to save their buffers frequently. For me, saving is like punctuation; I save whenever my typing pauses, out of reflex. Doesn't matter whether it's Emacs or NeoOffice or GMail or... do I use any other apps? Oh yeah, or the Gimp. When I pause, I save, and if you're a programmer I bet you do too. So occasional crashes may seem OK.

Another reason the crashes aren't called out more often is that most Emacs and XEmacs users are at best casual users. They open up an {X}Emacs session whenever they need to edit a file, and close it when they're done. It's just Notepad with colors and multi-level Undo.

If your average session length is shorter than the editor's MTBF, then yeah, you're not going to notice much crashing.

In contrast, your more... ah, seasoned (read: fanatical) Emacs users gradually come to live in it. Anything you can't do from within Emacs is an annoyance. It's like having to drive to a government building downtown to take care of some random paperwork they should have been offering as an online service a decade ago. You can live with it, but you're annoyed.

Even Firefox, the other big place I live, really wants to be Emacs. Tabs don't scale. Tabbed browsing was revolutionary in the same way adding more tellers to a bank was revolutionary: it's, like, 4x better. w00t. Emacs offers the unique ability to manage its open buffers in another first-class buffer, as a list. Imagine what your filesystem life would be like if the only view of a directory was one tab per file. Go to your pictures directory and watch it start vomiting tabs out like it tried to swallow a box of chiclets. Fun!

I feel sad when I see Eclipse users with fifty open tabs, an army of helpful termites eating away at their screen real-estate and their time.

I have a feeling I've veered off course somewhere... where was I? Oh yeah. Crashing.

So XEmacs has never been a particularly good tool for serious Emacs users because even though it's written in C, it crashes like a mature C++ application. You know the drill: major faceplants, all the fugging time.

Your ability to become an inhabitant of Emacs is gated by how stable it is. GNU Emacs has always been famously stable. Sure, the releases happen less frequently than presidential inaugurations. Sure, for a long time it always lacked some XEmacs feature or other. But it's really, really stable. Its MTBF is measurable in weeks (or even months, depending on what you're doing with it) as opposed to hours or days.

Emacs, like Firefox, can be configured to back up your state periodically, so that in theory it can recover after a crash. That's part of the problem: you didn't actually have to configure Firefox to get that behavior. It does it automatically. And to be honest, I've never had much luck with the Emacs save-state facilities. I'm a pretty competent elisp hacker these days, but the desktop.el has never worked reliably for me. I could probably get it to work, but I've always found it easier to write specialized startup "scripts" (lisp functions) that load up particular favorite configurations.

If I can't get desktop-save working, I'd guess that fewer than 1/10th of 1 percent of Emacs users use that feature. So crashes blow everything away.

If the state isn't being auto-saved, the next best thing is for it not to crash.

XEmacs never got that right.

Don't get me wrong...

I just realized I'm going to get screamed at by people who think I'm just an XEmacs-hater slash GNU-fanboy.

Make no mistake: I'm a fan of XEmacs. I think it was a great (or at least, necessary) idea in 1991. I think the execution, aside from the stability issue, was top-notch. I think it had a good architecture, by and large, at least within the rather severe constraints imposed by Emacs Lisp. I think it spurred competition in a healthy way.

I think the XEmacs development team, over the years, has consisted of engineers who are ALL better than I am, with no exceptions. And I even like certain aspects of the interface better, even today now that GNU Emacs has caught and surpassed XEmacs in features. For instance, I like the XEmacs "apropos" system better.

If you're going to scream at me for irrational reasons, it really ought to be for the right irrational reasons. Legitimate dumb reasons for screaming at me include: you're lazy and don't want to learn anything new; you invested a lot of time in XEmacs and don't see why you should be forced to switch; you are a very slow reader, causing you to skip three out of every five words I write, resulting in your receipt of a random approximation of my blog content, with a high error bar; you're still mad about my OS X blog. All good bad reasons.

Heck, you could even scream for rational reasons. Perhaps you have a philosophical beef with the FSF or GPL3. Perhaps XEmacs still has some vestiges of feature support that do not yet exist in GNU Emacs, and you truly can't live without them. I would think you're being a teeny bit uptight, but I would respect your opinion.

Whatever you do, just don't yell at me for thinking I'm dissing XEmacs or taking some sort of religious stance. Far from it. I just want a unified Emacs-o-cratic party.

XEmacs vs. GNU Emacs today

GNU Emacs pulled into the lead in, oh... I'd say somewhere around maybe 2002? 2003? I wasn't really keeping track, but one day I noticed Emacs had caught up.

Even today I maintain XEmacs/FSF-Emacs compatibility for my elisp files – some 50k lines of stuff I've written and maybe 400k lines of stuff I've pilfered from EmacsWiki, friends, and other sources. I still fire up XEmacs whenever I need to help someone get un-stuck, or to figure out whether some package I've written can be coerced to run, possibly in restricted-feature mode, under XEmacs.

For years I chose stability over features. And then one day GNU Emacs had... well, everything. Toolbars, widgets, inline images, variable fonts, internationalization, drag-and-drop in and out of the OS clipboard (even on Windows), multi-tty, and a long laundry-list of stuff I'd written off as XEmacs-only.

And it was still stable. Go figure.

I don't have the full feature-compatibility list. Does it even exist? You know, those tables that have little red X's if the Evil Competitor product is missing some feature your product offers, and little green checkmarks, and so on. We ought to make one of those. It would be useful to know what (if any) XEmacs features are preventing the last holdouts from migrating to FSF Emacs.

But for the past five years or so, just about every time an XEmacs user on a mailing list has mentioned a feature that's keeping them from switching, it's been solved.

If GNU Emacs isn't a perfect superset of XEmacs yet, I'm sure we could get it there if we had the big unified-platform carrot dangling in front of us. And I bet it's pretty close already.

Features and stability aside, XEmacs is looking pretty shabby in the performance department. Its font-lock support has never been very fast, and a few years back GNU Emacs took a giant leap forward. XEmacs can take 4 or 5 seconds or longer to fontify a medium-sized source file. Sure, it shows that big progress bar in the middle of the screen, so you know it's not dead, but when you're used to it being almost instantaneous, coming back to XEmacs is a real shocker.

And XEmacs has bugs. Man, it has a lot of bugs. I can't begin to tell you how many times I've had to work around some horrible XEmacs problem. It has bugs (e.g. in its fontification engine and cc-engine) that have been open for years, and they can be really painful to work around. I've had to take entire mode definitions and if-xemacs them, using an ancient version of the mode for XEmacs because nothing even remotely recent will run.

You may not notice the bugs, but as elisp developers, we feel the pain keenly.

Fundamental incompatibilities

As if issues with stability, performance and bugs weren't enough, XEmacs has yet another problem, which is that its APIs for dealing with UI elements (widgets and input events, but also including things like text properties, overlays, backgrounds and other in-buffer markup) are basically completely different from their GNU-Emacs counterparts. The two Emacsen share a great deal of common infrastructure at the Lisp level: they have mostly compatible APIs for dealing with files, buffers, windows, subprocesses, errors and signals, streams, timers, hooks and other primitives.

But their APIs range from mildly to completely different for keyboard and mouse handling, menus, scrollbars, foreground and background highlighting, dialogs, images, fonts, and just about everything else that interfaces with the window system.

The GUI and display code for any given package can be a significant fraction of the total effort, and it essentially has to be rewritten from scratch when porting from GNU Emacs to XEmacs or vice-versa. Unsurprisingly, many package authors just don't do it. The most famous example I can think of is James Clark's nxml-mode, which claims it'll never support XEmacs. I found that pretty shocking, since I thought it was basic Emacs etiquette to try to support XEmacs, and here James was cutting all ties, all public about it and everything. Wow.

But I totally understand, since I really don't want to rewrite all the display logic for my stuff either.

I'll be the first to admit: the API discrepancies are not XEmacs's fault. I can't see how they could be, given that for nearly all these features, XEmacs had them first.

For a developer trying to release a productivity package, it doesn't really matter whose fault it is. You target the platform that will have the most users. I don't know what XEmacs's market share is these days, but I'd be very surprised if it's more than 30%. That's a big number, but when you're an elisp hacker creating an open-source project in your limited spare time, that number can start looking awfully small. Teeny, even.

XEmacs should drop out of the race

At this point it's becoming painful to watch. GNU Emacs is getting all the superdelegates. That warmonger VIM is sitting back and laughing at us. But XEmacs just won't quit!

I'm sure there are a few old-timers out there who still care about the bad blood that originally existed between the two projects. To everyone else it's ancient history. As far as I can tell, there has been an atmosphere of polite (if subdued) cooperation between the two projects. Each of them has incorporated some compatibility fixes for the other, although it's still mostly up to package authors to do the heavy lifting of ensuring compatibility, especially for display code.

I haven't seen any XEmacs/GNU-Emacs flamewars in a long time, either. We're all just *Emacs users, keeping our community alive in the face of monster IDEs that vomit tabs, consume gigabytes of RAM, and attract robotic users who will probably never understand the critical importance of customizing and writing one's own tools.

When the Coke/Pepsi discussion comes up these days, it's usually an XEmacs user asking, in all seriousness, whether they should transition to GNU Emacs, and if so, would someone volunteer to help migrate their files and emulate their favorite behaviors.

Yes, someone will volunteer. I promise.

The dubious future of Emacs

I've got good news and bad news.

The good news is: Emacs is a revolutionary, almost indescribably QWAN-infused software system. Non-Emacs users and casual users simply can't appreciate how rich and rewarding it is, because they have nothing else to compare it to. There are other scriptable applications and systems out there — AppleScript, Firefox, things like that. They're fun and useful. But Emacs is self-hosting: writing things in it makes the environment itself more powerful. It's a feedback loop: a recursive, self-reinforcing, multiplicative effect that happens because you're enhancing the environment you're using to create enhancements.

When you write Emacs extensions, sometimes you're automating drudgery (always a good thing), sometimes you're writing new utilities or apps, and sometimes you're customizing the behavior of existing utilities. This isn't too much different from any well-designed scriptable environment. But unlike in other environments, sometimes you're improving your editing tools and/or your programming tools for Emacs itself. This notion of self-hosting software is something I've been wanting to blog more about, someday when I understand it better.

Eclipse and similar environments want to be self-hosting, but they're not, because Java is not self-hosting. In spite of Java's smattering of dynamic facilities, Java remains as fundamentally incapable of self-hosting as C++. Self-hosting only works if the code can "fold" on itself and become more powerful while making itself smaller and cleaner. I'm not really talking about macros here, even though that's probably the first thing you thought of. I'm thinking more along the lines of implementing JITs and supercompilers in the hosted runtime, rather than in the C++ or Java "hardware" substrate, which is where everyone puts them today.

I suspect (without proof) that in self-hosted environments, you can eventually cross a threshold where your performance gains from features implemented in the hosted environment outpace the gains from features in the substrate, because of this self-reinforcing effect: if code can make _itself_ faster and smarter, then it will be faster and smarter at making itself faster and smarter. In C++ and Java, making this jump to the self-reinforcing level is essentially intractable because, ironically, they have so many features (or feature omissions) for the sake of performance that they get in their own way.

To be sure, Emacs, the current crop of popular scripting languages, and other modestly self-hosting environments are all pretty far from achieving self-reinforcing performance. But Emacs has achieved it for productivity – at least, for the relatively small percentage of Emacs users who learn enough elisp to take advantage of it. There are just enough of us doing it to generate a steady supply of new elisp hackers, and the general-purpose artifacts we produce are usually enough to keep the current crop of casual users happy.

The bad news: the competition isn't the IDEs

I've argued that Emacs is in a special self-reinforcing software category. For productivity gains, that category can only be occupied by editors, by definition, and Emacs is currently way ahead of any competition in most respects. So most Emacs users have felt safe in the assumption that IDEs aren't going to replace Emacs.

Unfortunately, Emacs isn't immunized against obsolescence. It still needs to evolve, and evolve fast, if it's going to stay relevant. The same could be said of any piece of software, so this shouldn't be news. But it's particularly true for Emacs, because increasing numbers of programmers are being lured by the false productivity promises of IDEs.

They really are false promises: writing an Eclipse or IntelliJ (or God help you, Visual Studio) plugin is a monumental effort, so almost nobody does it. This means there's no community of building and customizing your own tools, which has long been the hallmark of great programmers. Moreover, the effort to create a plugin is high enough that people only do it for really significant applications, whereas in Emacs a "plugin" can be any size at all, from a single line of code up through enormous systems and frameworks.

Emacs has the same learning-curve benefit that HTML had: you can start simple and gradually work your way up, with no sudden step-functions in complexity. The IDEs start you off with monumental API guides, tutorials, boilerplate generators, and full-fledged manuals, at which point your brain switches off and you go over to see what's new on reddit. ("PLEASE UPMOD THIS PIC ITS FUNNY!")

And let's not even get into the Million Refactorings yet. It's a blog I've been working on for years, and may never finish, but at some point I'd like to try to show IDE users, probably through dozens or even hundreds of hands-on examples I've been collecting, that "refactoring" is an infinite spectrum of symbol manipulation, and they have, um, twelve of them. Maybe it's thirteen. Thirteen out of infinity – it's a start!

Programmers are being lured to IDEs, but the current crop of IDEs lacks the necessary elements to achieve self-hosting. So the only damage to Emacs (and to programmers in general) is that the bar is gradually going down: programmers are no longer being taught to create their own tools.

IDEs are draining users away, but it's not the classic fat-client IDEs that are ultimately going to kill Emacs. It's the browsers. They have all the power of a fat-client platform and all the flexibility of a dynamic system. I said earlier that Firefox wants to be Emacs. It should be obvious that Emacs also wants to be Firefox. Each has what the other lacks, and together they're pretty damn close to the ultimate software package.

If Emacs can't find a way to evolve into (or merge with) Firefox, then Firefox or some other extensible browser is going to eclipse Emacs. It's just a matter of time. This wouldn't be a bad thing, per se, but there's a good chance it would be done poorly, take forever, and wind up being less satisfying than if Emacs were to sprout browser-like facilities.

Emacs as a CLR

So Emacs needs to light a fire and hurry up and get a better rendering engine. Port to XUL, maybe? I don't know, but it's currently too limited in the application domains it can tackle. I realize this is a very hard problem to solve, but it needs to happen, or at some point a rendering engine will emerge with just enough editing power to drain the life from Emacs.

Emacs also needs to take a page from the JVM/CLR/Parrot efforts and treat itself as a VM (that's what it is, for all intents) and start offering first-class support for other languages. It's not that there's anything wrong with Lisp; the problem is X programmers. They only want to use X, so you have to offer a wide range of options for X. Emacs could be written in any language at all, take your pick, and it wouldn't be good enough.

RMS had this idea a long, long time ago (when he was making the rather controversial point that Tcl isn't a valid option for X), and it eventually led to Guile, which led more or less nowhere. Not surprising; it's a phenomenally difficult challenge. There are really only two VMs out there that have achieved even modest success with hosting multiple languages: the CLR and the JVM. CLR's winning that race, although it's happening in a dimension (Windows-land) that most of us don't inhabit. Parrot is... trying really hard. Actually, I should probably mention LLVM, which (like Parrot) was designed from the ground up for multi-language support, but took a lighter-weight approach. So let's call it four.

In any case, it's a small very group of VMs, and they still haven't quite figured out how to do it: how to get the languages to interoperate, how to get languages other than the first to perform decently, and so on.

This is clearly one of the hardest technical challenges facing our industry for the next 10 years, but it's also one of the most obviously necessary. And Emacs is going to have to play that game. I'm not talking about hacked-together process bridges like PyMacs or el4r, either — I mean first-class support and all that it entails.

I've mentioned the rendering engine and the multi-language support; the last major hurdle is concurrency. I don't know the answer here, either, but it needs an answer. Threads may be too difficult to support with the current architecture, but there are other options, and someone needs to start thinking hard about them. Editing is becoming a complicated business — too complicated for hand-rolling state machines.

Compete or die

So Emacs has some very serious changes ahead.

Let's face it: we're not going to see real change unless ALL the Emacs developers out there – today's crop of JWZs – band together to make it happen. But today we're divided. Two groups of brilliant C hackers working on separate, forked code bases? That's bad. Two groups of maniacal elisp hackers working on incompatible packages, or at best wasting time trying to achieve compatibility? Also bad.

Developers are starting to wake up and realize that the best "mainstream" extensible platform (which excludes Emacs, on account of the Lisp) is Firefox or any other non-dead browser (which excludes IE). Dynamic typing wins again, as it always will. Dynamic typing, property-based modeling and non-strict text protocols won the day for the web, and have resisted all incursions from heavyweight static replacements. And somehow the web keeps growing, against all the predictions and lamentations of the static camp, and it still works. And now the browsers are starting to sprout desktop-quality apps and productivity tools. It won't be long, I think, before the best Java development environment on the planet is written in JavaScript.

Emacs has to compete or die. If Firefox ever "tips" and achieves even a tenth of the out-of-the-box editing power of Emacs, not just for a specific application but for all web pages, widgets, text fields and system resources, Emacs is going to be toast. I may be the last rat on the ship, but I'm sure not going down with it; even _I_ will abandon Emacs if Firefox becomes a minimally acceptable extensible programmer's editor. This is a higher bar than you probably think, but it could happen.

We no longer need XEmacs to spur healthy competition. The competition is coming in hard from entirely new sources. What we need now is unity.

Then why not unify behind XEmacs?

I threw this in just in case you blew through the article, which I'd find perfectly understandable. To summarize, I've argued that XEmacs has a much lower market share, poorer performance, more bugs, much lower stability, and at this point probably fewer features than GNU Emacs. When you add it all up, it's the weaker candidate by a large margin.

Hence there's only one reasonable strategy: Hill, er, I mean XEmacs has to drop out of the race.

I'm really sorry about this. I'm a close personal friend of XEmacs, but I just can't endorse it anymore. I used to be a laissez-faire kinda guy, as long as you were using some flavor of Emacs. But at this point, if you're using XEmacs you're actively damaging not only your long-term productivity, but mine as well. So I'd like to ask you to think long and hard about switching. Soon.

If you're a local Emacs-Lisp guru, please offer your services to XEmacs users who would like to switch over. The more pain-free the migration is, the faster it will happen.

If you're a graphic artist, consider making a nice, tasteful "Euthanize XEmacs!" logo. Not that message, precisely, but something along those lines. Make sure it's tasteful. Perhaps "XEmacs is dead – long live XEmacs"? Yes, I think that would do nicely.

If you happen to know someone on the XEmacs development team, send them some chocolates, or movie tickets, or something. A thank-you, even. We should honor their service. But those guys are the most qualified on the planet to step in and start helping drive GNU Emacs forward, assuming the FSF team will have them. Emacs is in very bad shape indeed if they will not.

If you're a local system administrator, consider sudo rm -rf xemacs. Sorry, I mean consider politely asking your emacs-users mailing list if they might be willing to set a timeline for deprecating XEmacs, thereby starting the most massive flamewar in your company's history. Can't hurt!

If you're seeing red, and you skipped most of this article so you could comment on how amazingly lame this idea is, I recommend taking a little walk and getting some fresh air first.

If you're RMS, thank you for making Emacs and all that other stuff, and for keeping it free. Please be nice to those who wish to help. You're scary to the point of unapproachability, just 'cuz you're you.

XEmacs team, JWZ, and XEmacs package authors: thank you all for helping drive progress in the greatest piece of software of all time. I can only hope that someday I may have chops like that.

Now how about we turn this into the most famous reverse-fork in history?

74 Comments:

Blogger Srikanth said...

Steve Yegge, you are my hero!

:)

6:10 AM, April 28, 2008  
Blogger Sean said...

As soon as emacs gets proportional anti-aliased fonts, I'll switch. I can't go back to scratchy fixed width fonts.

6:16 AM, April 28, 2008  
Blogger leoboiko said...

installations from the debian popularity contest:

emacs21 30982
emacs22 18491
xemacs21 10795

sure, debian’s a limited sample, but damn people are still using xemacs!

shin_dig: I can’t tell why someone would want to run a text editor (as opposed to an word processor) in a proportional font — especially for programming. as for me, you can take my clean, lean, pleasantly monospaced Terminus font away from my cold, dead, RSI-damaged hands.

6:36 AM, April 28, 2008  
Blogger Mike Desjardins said...

I've been an XEmacs user for years now, mostly out of habit more than anything else. You may have just convinced me to give GNU Emacs another go. Hopefully my options file will play nicely with it! : )

6:41 AM, April 28, 2008  
Blogger AkitaOnRails said...

Great article, as always.

Which leads me to the question: I am not an Emacs user and I always see people like you talking about how cool the self-hosting environment is.

I also agree that IDEs like Eclipse, NetBeans, etc get in the way and I am never motivated to write a whole plugin to them.

I confess, I am a TextMate/Mac user. It is light-weight, bundles are easy to write, its reasonably customizable. More important of all: it has a Mac-alike GUI which is the utmost thing I can't stand in Emacs.

What I mean is, it made sense 20 years ago to have a terminal-non-GUI environment that is in itself almost an operating system.

But considering that we now live in a GUI world, be it Macs, Windows and even Linux with Gnome/KDE in spite of its 'terminal' heritage.

I don't need and I really don't want to have a text-based web browser within my editor. What's the point? I can't really see its design in a text-based web browser.

I really want drag & drop between multiple applications. It is a reality today that we multi-task between multiple applications that have to have integration between each other. It's just the way it is now.

So, what is really the point on Emacs? Don't get me wrong. I am really willing to try to learn it. But I never found a single article out there with a good enough reason to do so. The only thing that every article brags about is 'self-hosting', so please elaborate on how self-hosting environments can actually improve my productivity in comparison with other modern IDEs.

Best Regards

6:44 AM, April 28, 2008  
Blogger Charles Oliver Nutter said...

The CLR is *not* winning the multiple languages race, though they're making a good showing and catching up quickly. There are vastly more languages implemented for the JVM, and the JVM languages world has woken like a slumbering giant to enhance and improve those languages and starting bringing new ones over. The CLR, for all the noise, has only a handful of complete, useful languages implemented, and a substantial portion of those are Microsoft-controlled implementations. And dynamic languages can't even run efficiently on CLR without the help of a DLR to fill in the gaps that JVMs like HotSpot already do for us. It's time to end this "CLR is the best multi-language runtime" meme and realize that the JVM is just as good or better, and has had a lot more practice.

6:55 AM, April 28, 2008  
Blogger Leo Richard Comerford said...

Not to belittle Jamie Zawinski at all, but wasn't he the Unix guy on the Netscape Navigator v.1 team rather than its overall author? That's the impression I get from for example nscp dorm and his Wikipedia entry.

7:18 AM, April 28, 2008  
Blogger Unknown said...

While I totally agree with the main points of your article, I am surprised to hear that you consider XEmacs unstable. I do run it for weeks at the time without experiencing crashes. Currently using 21.4.

7:25 AM, April 28, 2008  
Blogger Doug Orleans said...

You already convinced me to switch away from XEmacs a few essays ago, but I haven't gotten around to it yet. But I will say, I've never had a problem with XEmacs stability. I won't say it never crashes, but it's in the single digits per year. It's more likely that Gnome will hang or something, and sometimes even then I can save XEmacs by switching to another TTY and restarting the window manager.

As for a Firefox/Emacs hybrid, what I really want is to embed an Emacs window in every textarea in Firefox. The "It's All Text!" plugin is close (with my editor set to gnuclient), but it's still just a bit too inconvenient to click the "edit" button rather than just have an Emacs buffer be right there.

7:30 AM, April 28, 2008  
Blogger Steve Cooper said...

It's often more fun to be captain of a small boat than a deckhand on a big ship.

If the XEmacs guys move over to GNUEmacs, will they get the same status they had under XE? Will Jamie Zawinski be co-consul with RMS? Or will he be punted somewhere lower down the pecking order, working on more peripheral stuff?

I suspect a lot of open-source projects face a similar challenge, which is why you get so many linux distros, KDE and Gnome, and about 5.6x10^7 MVC frameworks.

7:33 AM, April 28, 2008  
Blogger Kim Sullivan said...

Firefox with text editing capabilities? You mean, a text editor built upon the mozilla platform, with extensions and stuff? Something like OpenKomodo?

Or did you really mean integrating the capabilities in Firefox itself?

7:38 AM, April 28, 2008  
Blogger SonOfLilit said...

AkitaOnRails:

TextMate isn't 1e-10 times as customizable as emacs. It doesn't let you dig as deep. And the results show.

A text editor should be like a text field - it doesn't need menus, it doesn't need modern GUI buttons and dialogues and stuff. Just room for text. My emacs windows are borderless, menuless, toolbarless squares of TEXT (well, on the mac they have a shadow and a menu...). And in that, I have all I need. Emacs has a UI better suited for text editing than firefox or the OSX default UI.

Steve's point is that we DO need a REAL GUI browser in emacs.

You DO have drag and drop between emacs and the outside world.

Does this answer your points?

Just trying to help, hope you find the way that's right for you,

-- Aur

7:41 AM, April 28, 2008  
Blogger AkitaOnRails said...

@sonoflilit well, kind of.

As I said, I am not an Emacs user and that's the point: learning-curve.

I don't dispute that Emacs is more powerful than any other editor out there. I just used Textmate as an example of an editor that is nowhere near Emacs in terms of customizability, but nonetheless it gets my job done.

Java users would say the same about Eclipse.

So, what is the 'real' benefits of a self-hosting environment like Emacs? I can understand that a Lisp user love it. But what about non-Lisp lovers?

(by the way, sorry for the off-topic).

7:49 AM, April 28, 2008  
Blogger piyo said...

Your title stirs a tempest in a teapot. You should gone for "Emacs is Dead. Long Live Emacs!" When you're playing with fire, might as well use a flamethower. ;-)

> It won't be long, I think, before the best Java development environment on the planet is written in JavaScript.

You always amaze me with the scope of your predictions. I just hope there's no petty license squabbles along the way.

Perhaps we need to embed a self-hosting env into FF, one that doesn't require restarts. Why can't we just tack on Guile or extend JavaScript to do that? Oh, its just a "browser", not a rich client.

(GNU Emacs user 14 years and counting)

7:53 AM, April 28, 2008  
Blogger leoboiko said...

@sonoflilit: did you know that, apparently, OS X users pay actual money for the privilege of full-screen text editing? If only they knew how nice is a big black Emacs window maximized in my stumpwm…

8:08 AM, April 28, 2008  
Blogger Unknown said...

Forgive me for this, but I have to do it:
VIM FTW!!!

Sorry :)

8:22 AM, April 28, 2008  
Blogger BillSeitz said...

Is this just a sneaky way of preparing to drive us all to your NBE?

9:01 AM, April 28, 2008  
Blogger BillSeitz said...

Is this just a sneaky way of preparing us to move to your NBE?

9:04 AM, April 28, 2008  
Blogger petdog said...

Heh. I would love some kind of "buffer like" thing with a cairo canvas, on which I could draw with elisp. -- So, where do we go to buy some free megaseconds?

9:21 AM, April 28, 2008  
Blogger Alex Ott said...

There is also sxemacs project, that had forked XEmacs and try to extend it with many features, like multi-threading and so on.
GNU Emacs gain more success since 21st release, that had many features, not existing in XEmacs, and also has less troubles with multi-language environments (XEmacs all times had problems with non-latin fonts, etc - i had used XEmacs at 1997-2001)
Currently i look for a discussions about adding many IDE capabilities to GNU Emacs, and i like this approach.

9:24 AM, April 28, 2008  
Blogger Your Correspondent said...

It's past the time to move out of plain text and IDE's into mainstream Literate Programming.

Java should learn performance from the emacs byte-compiler. Emacs starts up a lot faster than any similarly-sized Java app; yet they are both bytecode systems.

It's also time to start mainstreaming voice input to complement the keyboard and mouse.

Bytecode systems are increasingly obsolete. It wouldn't be terribly hard to generate os-portable x86 machine code for OSX, Solaris, Linux or Windows. Only 2 kinds; 32-bit and 64-bit. Mediocre machine code will outperform bytecode.

9:35 AM, April 28, 2008  
Blogger Tessa Norris said...

A good, solid 90% solution would be someone with strong emacs-fu (I am
but tiny grasshopper) figuring out how to embed Gecko (WebKit would be
fine, too) into Emacs.

Gecko buffers in my buffer list would totally own. I could have one
integrated command line/address bar/search bar/find bar instead of
the several different command-line wannabees that Firefox has. And having everything in my buffer-list instead of tabs would be a towering victory.

Sure, it wouldn't have the same chrome control as XUL, the browser bits would require completely different extension techniques than the rest of emacs, and you wouldn't have the full multilingual support you're talking about, but, at least for my purposes, it would definitely quality as a 90% solution.

9:42 AM, April 28, 2008  
Blogger Nelson Elhage said...

> Port to XUL, maybe?

Are you familiar with conkeror? It's an emacs-inspired web browser built on top of XUL. While it currently only aspires to be a web browser, it's picking up an awful lot of the emacs nature, and I suspect that if someone wanted to, it could easily turn into a real emacs, but with a superior rendering engine and Javascript as the extension language.

10:36 AM, April 28, 2008  
Blogger Doug Orleans said...

Also, rumor has it that Microsoft is working on their own Bizarro-world Emacs. Maybe that'll be the solution!!

10:45 AM, April 28, 2008  
Blogger Stephen said...

From about '79, i've been using flavors of emacs, starting with FINE (Fine Is Not Emacs) and it's bigger brother COURSE. The original EMacs used ITS TECO as it's extension language. As a TECO user, it was natural to jump into EMacs, and still be able to write powerful one-off editing scripts. I recall doing a matrix transpose in TECO off the top of my head. It was five minutes to write it, and ten minutes to execute (on a .2 MIPS pdp-10).

In the '80s, my variant of choice was Jove - i had binaries that ran on the Mac, DOS and Unix, the three places i was in most. DOS died, and the Linux version became xjove, and my fingers didn't know how to use it. The original version died with glibc2. Meanwhile, in the late 80's, the 386/25 was the first machine that started up Emacs fast enough (4 to 10 MIPS, depending on how you counted it.) And then GNU Emacs kept changing the rules for how to set ^h to 'back-hacking-tabs'. Really, i want to build on what i know, not have to relearn everything i know. How am i supposed to make progress?

I've never gotten very far into Lisp and variants, though i've been goofing with Guile of late. Far from using a Turing complete language to edit my files, i'm now stranded with keyboard macros, and i tell them to run a million times, stop on ringing the bell. My Emacs experience has become so limited, i've started using Vim. And liking it. Yet, my peers know even less about editing, and want me to make the big sweeping changes, because all they know is copy and paste.

I really don't want Emacs to replace Eclipse as my operating system. Eclipse would be a good IDE, if it was slimmer. 10000x slimmer. Turbo C 2.0 worked on a 640k DOS machine. Think C was awesome on a 1 MIPS 68K Mac with 2 MB RAM. Awesome. Now i can't bring up the editor without 2 GB RAM and a cup of coffee. I don't even drink coffee. Maybe i should get a new 1 MIPS 68K Mac.

TECO is a line noise language. But it has very little indirection, so it can be learned quickly. It's a stack language, so could be thought of as Forth, but very much special purposed. It doesn't have the verbosity of Scheme, Lisp or Java. So the commands can be interpreted as is, and very fast. Who needs byte code? There was quite a bit to be said for it. I'm not suggesting that we switch back.

However, i'm convinced that the quality of Lisp code out there has more to do with the barrier to entry than anything inherent in the language. The barrier to entry is high, so the really bad drivers stay home. Of course the code is better. And Gabriel dispairs that really good looking Lisp code runs really slow. You can't tell by looking. He is correct that C programmers are unable to make this kind of mistake. And if you're not supposed to use call/cc (Scheme) because the result is unpredictable in time, space and, well, what is it going to do, then you have a language that is recursive, like C is, or at least almost as good. What of it? Why not use C, which can be compiled to the bare metal, and by the way, is still the gold standard for speed? Garbage collection? That may be all you get.

I couldn't tell you which Emacs i have on my Linux box. Did i say "sudo apt-get install emacs", or did i say "sudo apt-get install xemacs". But apparently, when i needed an editor at work, it was a Windows Emacs package that came up first in the search. It wasn't because Emacs is more reliable or has fresh minty taste. If that's why you think Emacs is becoming more popular than xemacs, you've got some more karma to work out.

10:51 AM, April 28, 2008  
Blogger Dan Lewis said...

There's a library called saveconf.el distributed with Xemacs that saves and retrieve buffer states. It reminds me of my beloved save-tabs-on-exit in Firefox 3b5. If you added a timer to save-context it would probably go a long way to save and recovery on crash.

I looked at desktop.el, which looks like it saves a lot more than saveconf.el. But it seems to me that a lot of what desktop.el saves is stuff that you tend to set through your .emacs anyway.

saveconf.el

Thanks for all the Emacs articles, by the way. You convinced me to switch about a month ago and it continues to be a mind-blowing experience.

10:57 AM, April 28, 2008  
Blogger Unknown said...

> As soon as emacs gets proportional anti-aliased fonts, I'll switch. I can't go back to scratchy fixed width fonts.

It does. It's not in the last released version (emacs22), but it's in what will become emacs23, and your distribution might have packaged a prerelease version.

Screenshots:

http://peadrop.com/blog/2007/01/06/pretty-emacs/
http://times.usefulinc.com/2005/12/02-emacs-xft

11:16 AM, April 28, 2008  
Blogger dbt said...

I was a die-hard xemacs user from 1996 until early 2008. I was already a doubting thomas, but Aquamacs put the final stake in it (of course, RMS doesn't like Aquamacs either, but that's another story).

11:17 AM, April 28, 2008  
Blogger Unknown said...

To the Textmate/Mac user: check out Aquamacs at aquamacs.org -- it's an OS X / Aqua port of Emacs. Very nice.

Does emacs have a Bugzilla or Trac system going yet? I remember some old argument about that hampering its development.

12:07 PM, April 28, 2008  
Blogger Alex Ott said...

GNU Emacs now has debian-style bug reporting system

12:14 PM, April 28, 2008  
Blogger Vesa said...

You found it! The way to embrace both Javascript and Emacs. You are my hero.

12:40 PM, April 28, 2008  
Blogger displayname said...

And you thought I'd given up on controversial blogs.
you're still mad about my OS X blog.
It's a blog I've been working on for years

A blog is a sequence of posts. Please stop using "blog" to mean "blog post". Thank you.

Other occurrences on the page that indicate you know this already:
A dude with arguably the best cat-picture blog ever created.
Keep up the cat blog.
Stevey's Personal Blog

1:21 PM, April 28, 2008  
Blogger Unknown said...

Well, I had written a longish rant about Firefox as a platform or building an extensible editor being a crazy-but-possibly-brilliant idea with a huge amount of scope.

I made the point that all it really needs is a solid text editing component that can handle all the stuff you need for a typical editor (syntax highlighting, mainly), and the rest is relatively simple.

I mentioned that Javascript is (I assume) far more widely known than emacs-lisp, and very easy to learn.

But Firefox crashed and I lost it all. Read into that what you will :)

1:29 PM, April 28, 2008  
Blogger leoboiko said...

Maybe stevey's not using the normal word "blog" (hereafter "blog¹") at all. I think he's nominalizing the verb "to blog²" to create a new noun "blog³", like this:

I borked this yesterday -> I made a bork yesterday
I grokked something today -> I had a grok today
I blogged² about OSX -> I worked on a blog³ about OSX.

That there was already a noun "blog¹" with a different meaning is irrelevant to this proccess; what matters is that the verb "to blog²" means "to create a blog¹ post", not "to create a blog¹". Thus, blog³ = blog¹ post.

Since blog¹ is actually the source of "to blog²", blog³ is a case of re-nominalization of a verbalized noun, with a shift in semantics along the way!

1:38 PM, April 28, 2008  
Blogger Jonathan Millett said...

I'm holding out for the combined self hosting emacs, firefox, wow program.

1:59 PM, April 28, 2008  
Blogger ferruccio said...

All this time I thought XEmacs was just Emacs with a GUI front end. Thanks for clearing that up for me!

2:15 PM, April 28, 2008  
Blogger Andrew Stine said...

I honestly don't think that you could truly make emacs into a multi-language platform without destroying some of the 'self-hosting' properties of it. You would need a system that could intermingle function calls and variables from various languages. This strikes me as a rather convoluted task as the languages that would be good candidates, (Python, Ruby, basically dynamic languages) tend to seem to have incompatible features. I try to imagine integrating Ruby's object system into e-lisp or trying to call a macro from Python, and it seems like that for the languages to interoperate, you'd have to loose the a lot of the meta-programming techiniques from all languages which make them so popular in the first place, or, at least restrict them so they don't carry over between languages.

2:16 PM, April 28, 2008  
Blogger Stuart Hacking said...

Aren't you using a mac now? The you might like http://aquamacs.org/

Think GNU Emacs but it behaves like a Mac application. I used it since switching and haven't been disappointed thus far.

2:37 PM, April 28, 2008  
Blogger 米国人 said...

The McCain/Obama/Clinton reference in "At this point it's becoming painful to watch. GNU Emacs is getting all the superdelegates. That warmonger VIM is sitting back and laughing at us. But XEmacs just won't quit!" was badass. You're the man, Stevie. :)

3:18 PM, April 28, 2008  
Blogger Unknown said...

SonOfLilit said “TextMate isn't 1e-10 times as customizable as emacs.”

You're speaking from ignorance here. The declarative nature the majority of its customizations means that most TextMate bundles progress at a much faster rate than emacs modes. Its scope system make them in many ways more flexible and powerful.

The addition of tm_dialog, and built-in WebKit, mean that TextMate can already do some of the things Steve is talking about in this post. But give it another few years, and it will have pushed much more significantly beyond Emacs.

If you haven't tried it you don't know what you're missing. Either way, Emacs is going to need to adopt many TextMate features in the coming years, if it hopes to compete, a very difficult or even impossible feat, as it will mean breaking backwards-compatibility with existing Emacs infrastructure.

3:37 PM, April 28, 2008  
Blogger Unknown said...

You mentioned having trouble setting up desktop.el. Here's my solution:

(require 'desktop)
(defun david-session-start ()
(interactive)
(david-kill-C-x-C-c)
(desktop-read)
(run-with-timer 0 120 'desktop-save "~/"))

(defun david-kill-C-x-C-c ()
(interactive)
(define-key global-map [(control x) (control c)] (lambda () (interactive) (message "No! Use the mouse!"))))

david-kill-C-x-C-c just saves me from fat-fingering C-x C-c and ending my emacs session.

I manually run M-x david-session-start on my One True Emacs (tm) session. That way when I run emacs on some random file from the terminal I don't have to worry about it loading my 8 million buffers from my .desktop file.

I completely agree with you about XEmacs. I used XEmacs for a long long time, but switched over to GNU Emacs at around pre-version 21 when it suddenly had almost everything that XEmacs had. My one missing feature is good tab completion in the M-x compile minibuffer. XEmacs has awesome tabbing which makes "make -C ~/src/some-random-directory" extremely pleasant. GNU Emacs still doesn't do this (by default).

7:29 PM, April 28, 2008  
Anonymous Anonymous said...

There are some very interesting points in this post--interesting enough that you may have finally tipped me over the edge and convinced me to switch away from vim...to Yi.

Yi goes a step beyond Emacs or Firefox in that the entire editor is written in its "scripting language"--not a line of C. (Well, some non-core stuff does link to a few C libraries, such as gtk2, but those libraries could be replaced, though I wouldn't see much point in it.) It does this without performance penalty by not only embedding an interpreter in the editor, but a full compiler, and one that does pretty well in the performance shootouts.

I just need to find the time....

7:51 PM, April 28, 2008  
Blogger stephen@xemacs said...

We work on XEmacs because it's more fun to work on this code than on other code. That's all there is to it.

Time to get back to havin' fun!

9:31 PM, April 28, 2008  
Blogger j said...

I am still a neophyte, but I love GNU-Emacs. If I could browse websites in it, I would (I know there are packages, but I am still too inexperienced to set them up). I love the buffers, dired, occur, and grep-find. I have written some simple ELISP stuff, and I like LISP, even tho it is difficult to approach sometimes.

I find that I spend most of my time in Emacs, and that time is more productive than time I spend in Visual Studio, or any other editor or IDE that I have tried, for that matter.

I think without ELISP, Emacs wouldn't be anywhere near as useful. I wish LISP was used more.

10:07 PM, April 28, 2008  
Blogger David Moles said...

So what is the GNU Emacs equivalent of set-buffer-file-coding-system-for-read, anyway? That's the only thing I really miss.

12:56 AM, April 29, 2008  
Blogger FDominicus said...

Crashing? At least not on me but in some beta version and then also during some migration from Xfree to Xorgs X11 variant.

One of my xemacs is now alive for
> 180 days. It just sits around waiting for me to reconnect ;-)

The only thing that might get me away from XEmacs is another Emacs extensible with Common Lisp, Smalltalk, Ruby or Io.

I can not even stand the FSF tries any longer on selling varpoware for me. Since the 1999 or so the are talking about a Guile-Emacs, and where is it?

Another thing which might seduce me to try is a really good gnome or kde or the like integrated (X)Emacs

But this will not happen anytime soon and so I'm happy hacking away on my good 'ol XEmacs

Regards
Friedrich

1:38 AM, April 29, 2008  
Blogger Unknown said...

Thanks Stevey, you have also inspired me to get cracking at improving rails-mode for emacs.

3:37 AM, April 29, 2008  
Blogger Manc Trader said...

Great post. I wish this would happen. I am not a programmer but a long time emacs user. I do use a lot of the R and S programming language and a couple of years ago moved over to gnu emacs after over 6 years of xemacs. I am glad I did.
I just wish all the brains developing for emacs would get back under the same tent.

5:32 AM, April 29, 2008  
Blogger Unknown said...

You mentioned self hosting development system and it reminded me of working in smalltalk/squeak. You write your code in the environment, compile and execute it as well as saving the state of all existing object instances.

Obviously everyone isn't beating down the door of the smalltalk/squeak crowd but Dan Ingalls created a similar environment in a browser using javascript and called it the Lively Kernel. I found this in the Weekly Squeak.

6:28 AM, April 29, 2008  
Blogger Manc Trader said...

I would love to hear Steve comment on conkeror that was menitoned in a post above. I am curious about the prospects of that project.

7:36 AM, April 29, 2008  
Blogger Arslan ibn Da'ud said...

Is there a Firefox extension that lets you add snippets of Javascript to your browser itself? Sort of like what greasemonkey does for individual webpages? That would be the main way to make Firefox more emacs-like....with Javascript. Extending it with C, the way most extensions do has one fatal flaw...a bad extension can crash the browser. You generally can't crash Emacs with bad Elisp.

I like Greasemonkey, but (last I tried it), it makes browsing slower...it seems to be linear with the number of GM scripts you bolt on.

For that matter, the original Netscape let you edit HTML pages...can't you do that in Mozilla as well? Making the browser into an HTML editor has been tried before.

For that matter, adding elisp scripting has been done several places...metacity (the GNOME window manager) comes to mind.

9:00 AM, April 29, 2008  
Blogger Xach said...

Lispworks still sells Liquid Common Lisp, née Lucid Common Lisp. The Lispworks Lisp product itself is not from Lucid.

9:56 AM, April 29, 2008  
Blogger Dan Ingalls said...

Hey, Steve -

Great to hear your perspective. Much of this I share from a long history with Squeak.

We have just put together the makings of "another run at the fence" in JavaScript that might interest you. It's called The Lively Kernel, and it's a self-supporting system on a web page. We're just now getting many of the tools working (a new release due out next week), so you might be interested to take a peek.

Check it out (somewhat old version) at
http://research.sun.com/projects/lively/

12:55 PM, April 29, 2008  
Blogger Manc Trader said...

I did some googling inspired by this post and found the most recent two posts at the following blog very interesting. Not only is the guy using emacs. firefox with the firemacs add on + conkeror but is also using a window manager configurable in common lisp which he does using slime from emacs

http://bc.tech.coop/blog/index.html

interesting setup.

4:00 PM, April 29, 2008  
Blogger lahosken said...

"If Emacs can't find a way to evolve into (or merge with) Firefox, then Firefox or some other extensible browser is going to eclipse Emacs."

Dude, just because you can't figure out how to switch between windows on that weird Mac you picked up, don't make us smoosh all of our apps into one window^W app^W thingy^W whatever.

9:57 PM, April 30, 2008  
Blogger Per Abrahamsen said...

Please don't turn Emacs into a multi-language platform..

I agree with most of your other points, the world would be better of without XEmacs, and sharing backend with a popular browser (gecko, webkit...) would be an interesting path.

BTW: Gerd Moellmann is the main person responsible for dragging Emacs into the 90', he was maintainer and lead programmer for Emacs 21. He keeps a low profile on the net, so he doesn't get the recognition he deserves.

2:34 AM, May 02, 2008  
Blogger smarks said...

You make a good point about Emacs being self-hosting, but I don't think it's actually quite right. If Emacs were self-hosting, then the Lisp core would be written in Lisp. Last time I looked the core pieces of Emacs were still written in C.

Still, Emacs has some really attractive properties: it's extensible (of course) and it's reflective (or perhaps introspective) in that its extension language can inspect and modify itself. Or at least large pieces of itself. I think that's what makes Emacs really cool. Other systems, such as Smalltalk and the Lively Kernel, referenced above, share these properties.

By the way, I think it is possible for Java to be truly self-hosting. There is a SunLabs project Maxine to investigate exactly this. Unfortunately it doesn't look like they've published any reports yet, so I can't say much more. (I don't work on the project, but I have talked to the researchers.)

6:36 PM, May 02, 2008  
Blogger brett said...

I hope they make elisp tail-recursive before emacs becomes some mutant cross-language platform thingy. I keep getting bit by the no tail-recursion thing , you'd think I would have learned by now.

6:04 PM, May 03, 2008  
Blogger Unknown said...

Hi Steve,

I became aware of your blog maybe about a year ago, and have since read it periodically. More so regularly in recent months. Of all your writings, i almost agree whole heartedly, and the more i read, the more i see the years of experience and wisdom behind it.

However, there's something out of the ordinary today. You wrote:
«I'd also count among their legacies an absolutely outstanding collection of software essays called Patterns of Software, by Lucid's founder, Richard P. Gabriel. I go back and re-read them every year or so. They're that good.»

I'd consider that book one of the worst about computing i've ever read. More specifically, the first part of the book, i consider pure garbage, damaging to software community in a way similar to how religious people preachs about life-after-death or reincarnation or other troubling untruths. I wrote a review of this book in 1998: http://xahlee.org/PageTwo_dir/Personal_dir/bookReviewRichardGabriel.html

About Xemacs.... i heartily agree with you about its significance in the history of emacs. In my words, about maybe 4 years of commercial development (of xemacs), took the OpenSource/FreeSoftware camp 1.5 decade to catch up. For me, i started to use emacs in 1998, and from 1998-2005, i'm using xemacs 100% of the time purely for practical reasons. My experiences of using them is sum'd up here: http://xahlee.org/emacs/emacs_vs_xemacs.html

About your thesis that emacs is under threat of platforms such as modern browser... i think it is a very insightful point.

Making changes to emacs in some fundamental way wont be easy, not when RMS is ruling the party. Recently, his last email to me was “please don't be ridiculous”. All things considered, i think he's being somewhat rather rude. (For now, that was the last email between us. And, i think that effectly stopped me from wanting to contribute back to FSF on emacs, either of existing code or ideas)

It is relatively easy to contribute to FSF emacs by snippets of code, or a module. However, to change it in atypical way, such as modernize its documentation out of its 1980's context and writing in a systematic non-trivial update, or modernize its GUI out of the build up from 1980's ways, or, as you suggest, introducing or integrating or embracing some VM... am afraid will be nigh impossible, or take a long, long, long, time.

For me, i feel the most urgent change emacs needs is a few basic interface changes, detailed here: http://xahlee.org/emacs/modernization.html

The most effective method to make a stratedgic change, is, like Xemacs has done, or as Aquamacs has done, by simply having a capable person fork his own version with his vision, out in the public. If we assume that his idea is good, it will amass users quickly in a few short years, then, the GNU emacs will quickly adapt. This doesn't necessarily suggest dark politics or other conspiracy theories. It's just how the world works, by natural competition.

I didn't write this reply preplanned... but now at this point, i'm thinking, Steve: you are the one.

Xah
xah@xahlee.org
∑ http://xahlee.org/

11:08 PM, May 03, 2008  
Blogger Pete Mao said...

Re: aquamacs

I had it for less than 5 minutes on my computer. It had some weird behavior that I could live with. Something like, killing all the open buffers would close the application, instead of leaving a *scratch* buffer. Also, there may have been some bizzare frame (C-x 5 C-f) behavior. Anyways, it spooked me enough to make me realize that it's not *real* emacs.

11:25 PM, May 03, 2008  
Blogger jmdesp said...

Steve, we are Mozilla. You will be assimilated. Resistance is futile. Start coding that emacs extension for Firefox now, instead of losing time trying to resist. Conqueror is a good first step, but it needs improvements. You are the man for that.

;-)

6:42 AM, May 04, 2008  
Blogger Amanjit Singh Gill said...

You have to settle on some cross-platform-editor. Emacs is just an editor. But I can't stand RMS, that software socialist.

Therefore I use XEmacs, because it's much more liberal in my eyes. If XEmacs dissapears, I would stop using any kind of emacs.

11:04 AM, May 04, 2008  
Anonymous Anonymous said...

>And you thought I'd given up on controversial blogs. Hah!

I for one hope you never do...
Great article!

11:35 AM, May 05, 2008  
Blogger Dan Weinreb said...

I've been using XEmacs for a few years and have not seen any of the instability you're talking about; and I leave XEmacs instance running for a long time. (I'm just using XEmacs instead of Emacs because the people around me were; no strong reason.)

It would be nice to have a complete reimplementation of Emacs in more modern technology. But it's really a huge amount of work. I say this from experience. I wrote the second Emacs ever: the Lisp machine implementation, whose spec was "do what Stallman's PDP-10 (original) Emacs does", and then progressed from there.

There's just a whole LOT of it. It took me and Mike McMahon endless hours to implement so many commands to make ZWEI/Zmacs.

Now, if you mean reimplement the core of GNU [X]Emacs, the stuff that's written in C, so that the existing elisp can all be used, that's more realistic. But I'm not sure that the benefits are worth the work. There's so much else to do.

3:31 AM, May 15, 2008  
Blogger John Cowan said...

The "ex" troglodyte speaks:

I don't want an editor to be configurable, extensible, self-hosting, or anything else. I want it to be the same everywhere, so that when I use it, I don't *use* it, I *am* it. When I type, it's not "I tell my fingers what to type", I just type. Likewise, when I edit with "ex" (after I had to give up Teco) I don't use "ex", I just edit. I no more notice what commands I am using, 99% of the time, than I notice what muscles I am using to type them.

The only problems I've had is that "vi" is usually Vim on modern systems, and all versions of Vim before 7.0 were abysmal implementations of "ex". To give you an idea, I had to make sure never to use the undo command, because it would undo everything you'd done since the last time you were in "vi" mode, which in my case was never! So everything got undone back to the point where I started to edit.

I now install the Heritage Toolkit "vi" everywhere I can't upgrade Vim or replace it with Nvi or the like. It will run nicely out of ~jcowan/bin, modulo the broken /etc/termcap, but terminal support doesn't add that much to "ex".

Don't think, though, that I don't appreciate working in a framework with near-infinite extensibility. I do; it's called the shell.

9:16 AM, May 22, 2008  
Blogger bolognese said...

>> As soon as emacs gets proportional
>> anti-aliased fonts, I'll switch. I
>> can't go back to scratchy fixed width
>> fonts.

GNU Emacs 23 (wich is under active development and can be installed on debian/ubuntu systems as 'emacs-snapshot') does support proportional and anti-aliased vector fonts.

3:03 PM, June 11, 2008  
Blogger bolognese said...

i almost forgot that....

http://fjl.wurzelzwergundmaerchenfee.de/img/euthanize.png

4:02 PM, June 11, 2008  
Blogger Bernard (ben) Tremblay said...

I tweeted a coupla wh00ts about UltraEdit and a buddy pointed me to this post.
Ok, so I don't use XEmacs.
But I gotta say: finding an article like this refreshes my belief that there's sentient life on Spaceship Earth.

wh00t wh000t!

7:58 PM, June 26, 2008  
Blogger Justin Goldberg said...

What we need is hardware accelerated lisp machines, and a complete lisp os.

3:00 PM, August 21, 2008  
Blogger Stephan Beal said...

Dude, i've been using xemacs nearly every day since 1997 and i think it's crashed on me 1 time, maybe 2. My current session has been open since 5 or 6 days. Your article makes it sound as if xemacs is somehow unstable. Perhaps you were always working from the CVS Head?

2:57 AM, September 05, 2008  
Blogger an0 said...

Good job. I am eager for the unification.
As to the fundamental problems to solve, IMO, a better(maybe just little more modern and more fit in the whole desktop system each installation of Emacs inhabits) GUI is the most straightforward and effective way to gain more converts for Emacs, if it is not only geeks that we want to attract.

11:25 PM, September 09, 2008  
Anonymous Anonymous said...

'm pulling a Yegge. Point is, use both. Use the dynamic side enough to find the static side ridiculous

1:31 AM, September 18, 2008  
Anonymous Anonymous said...

I can't go back to scratchy fixed width fonts.

1:33 AM, September 18, 2008  
Blogger Oleg said...

I have used XEmacs for 10 years now. I never recall it crashing, and I keep an XEmacs session open with half a hundred buffers for many, many months. I tried switching to Emacs lately (the new one with antialiased fonts), but it was so slow to refresh its windows when switching desktops that I gave up on it. The VNC session may be to blame, but XEmacs is less of a laggard in that respect, even with antialiased fonts.

1:38 AM, December 28, 2009  

Post a Comment

<< Home