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 ocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r accomplishments, wrote cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 original Netscape Navigator and cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 original XEmacs. A guy who can use cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 term "downward funargs" and cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365n glare at you just daring you to ask him to explain it, you cretin. A dude with arguably cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365m 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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365n. I still marvel at his work, and his shocking writing style, when I'm grubbing around in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 guts of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 Emacs-Lisp byte-compiler.
It makes you wonder how many of him cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365re are out cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365re. You know, programmers at that level. He can't be cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 only one. What do you suppose cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365y're all working on? Or do cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365y all eventually make 25th level and opt for divine ascension?
In any case, I'm sad that I have to write cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 obit on one of his greater achievements. Sorry, man. Keep up cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 cat blog.
Forking XEmacs
I have to include a teeny history lesson. Bear with me. It's short.
XEmacs was a fork of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 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, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ir two big software legacies still extant are a Lisp environment now sold by LispWorks, and XEmacs.
I'd also count among cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ir 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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365m every year or so. They're that good.
Back when XEmacs was forked, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365re were some fireworks. Nothing we haven't seen many times before or since. Software as usual. But cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365re was a Great Schism. Nowadays it's more like competing football teams. Tempers have cooled. At least, I think cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365y have.
As for cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 whole sordid history of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 right decision at cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 time, just as decomissioning it is cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 right decision today, seventeen years later.
XEmacs dragged Emacs kicking and screaming into cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 modern era. Among many ocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r 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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 evolution of GNU Emacs during cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 mid- to late-1990s. GNU Emacs was always playing catch-up, and cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 mid-1990s: cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 most important survival traits of a software system is that it should never reboot. Emacs and XEmacs are at cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 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) cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 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 ocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r 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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 reasons are, since cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365re's no excuse for it.
Interestingly, most XEmacs users I've talked to say cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365y don't notice cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 crashing rarely has an impact. It even restores your state properly most of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 good ones do.
XEmacs may crash even less than Eclipse and IntelliJ. Crashing editors usually aren't a big problem. Programmers all learn cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 hard way to save cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ir buffers frequently. For me, saving is like punctuation; I save whenever my typing pauses, out of reflex. Doesn't matter whecá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r it's Emacs or NeoOffice or GMail or... do I use any ocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r apps? Oh yeah, or cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 Gimp. When I pause, I save, and if you're a programmer I bet you do too. So occasional crashes may seem OK.
Anocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r reason cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365y need to edit a file, and close it when cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365y're done. It's just Notepad with colors and multi-level Undo.
If your average session length is shorter than cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 editor's MTBF, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365n 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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365y should have been offering as an online service a decade ago. You can live with it, but you're annoyed.
Even Firefox, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 ocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r big place I live, really wants to be Emacs. Tabs don't scale. Tabbed browsing was revolutionary in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 same way adding more tellers to a bank was revolutionary: it's, like, 4x better. w00t. Emacs offers cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 unique ability to manage its open buffers in anocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r first-class buffer, as a list. Imagine what your filesystem life would be like if cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ir screen real-estate and cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ir 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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 drill: major faceplants, all cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 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, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 releases happen less frequently than presidential inaugurations. Sure, for a long time it always lacked some XEmacs feature or ocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r. 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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ory it can recover after a crash. That's part of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 Emacs save-state facilities. I'm a pretty competent elisp hacker cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365se days, but cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365
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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 state isn't being auto-saved, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 execution, aside from cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 stability issue, was top-notch. I think it had a good architecture, by and large, at least within cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 racá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r severe constraints imposed by Emacs Lisp. I think it spurred competition in a healthy way.
I think cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 XEmacs development team, over cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 years, has consisted of engineers who are ALL better than I am, with no exceptions. And I even like certain aspects of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 interface better, even today now that GNU Emacs has caught and surpassed XEmacs in features. For instance, I like cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 XEmacs "apropos" system better.
If you're going to scream at me for irrational reasons, it really ought to be for cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365m. 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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 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 ocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r sources. I still fire up XEmacs whenever I need to help someone get un-stuck, or to figure out whecá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r 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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365n one day GNU Emacs had... well, everything. Toolbars, widgets, inline images, variable fonts, internationalization, drag-and-drop in and out of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 full feature-compatibility list. Does it even exist? You know, those tables that have little red X's if cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 last holdouts from migrating to FSF Emacs.
But for cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 past five years or so, just about every time an XEmacs user on a mailing list has mentioned a feature that's keeping cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365m from switching, it's been solved.
If GNU Emacs isn't a perfect superset of XEmacs yet, I'm sure we could get it cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365re if we had cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 middle of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365y can be really painful to work around. I've had to take entire mode definitions and
if-xemacs
cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365m, using an ancient version of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 mode for XEmacs because nothing even remotely recent will run.You may not notice cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 bugs, but as elisp developers, we feel cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 pain keenly.
Fundamental incompatibilities
As if issues with stability, performance and bugs weren't enough, XEmacs has yet anocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r 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 ocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r in-buffer markup) are basically completely different from cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ir GNU-Emacs counterparts. The two Emacsen share a great deal of common infrastructure at cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 Lisp level: cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365y have mostly compatible APIs for dealing with files, buffers, windows, subprocesses, errors and signals, streams, timers, hooks and ocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r primitives.
But cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ir 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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 window system.
The GUI and display code for any given package can be a significant fraction of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 display logic for my stuff eicá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r.
I'll be cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 first to admit: cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 API discrepancies are not XEmacs's fault. I can't see how cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365y could be, given that for nearly all cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365se features, XEmacs had cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365m first.
For a developer trying to release a productivity package, it doesn't really matter whose fault it is. You target cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 platform that will have cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 most users. I don't know what XEmacs's market share is cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365se 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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 race
At this point it's becoming painful to watch. GNU Emacs is getting all cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 superdelegates. That warmonger VIM is sitting back and laughing at us. But XEmacs just won't quit!
I'm sure cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365re are a few old-timers out cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365re who still care about cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 bad blood that originally existed between cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 two projects. To everyone else it's ancient history. As far as I can tell, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365re has been an atmosphere of polite (if subdued) cooperation between cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 two projects. Each of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365m has incorporated some compatibility fixes for cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 ocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r, although it's still mostly up to package authors to do cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 heavy lifting of ensuring compatibility, especially for display code.
I haven't seen any XEmacs/GNU-Emacs flamewars in a long time, eicá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r. We're all just *Emacs users, keeping our community alive in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 face of monster IDEs that vomit tabs, consume gigabytes of RAM, and attract robotic users who will probably never understand cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 critical importance of customizing and writing one's own tools.
When cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 Coke/Pepsi discussion comes up cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365se days, it's usually an XEmacs user asking, in all seriousness, whecá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365y should transition to GNU Emacs, and if so, would someone volunteer to help migrate cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ir files and emulate cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ir 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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365y have nothing else to compare it to. There are ocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r scriptable applications and systems out cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365re — AppleScript, Firefox, things like that. They're fun and useful. But Emacs is self-hosting: writing things in it makes cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 environment itself more powerful. It's a feedback loop: a recursive, self-reinforcing, multiplicative effect that happens because you're enhancing cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 behavior of existing utilities. This isn't too much different from any well-designed scriptable environment. But unlike in ocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r 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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365y'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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 first thing you thought of. I'm thinking more along cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 lines of implementing JITs and supercompilers in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 hosted runtime, racá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r than in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 C++ or Java "hardware" substrate, which is where everyone puts cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365m today.
I suspect (without proof) that in self-hosted environments, you can eventually cross a threshold where your performance gains from features implemented in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 hosted environment outpace cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 gains from features in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 substrate, because of this self-reinforcing effect: if code can make _itself_ faster and smarter, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365n it will be faster and smarter at making itself faster and smarter. In C++ and Java, making this jump to cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 self-reinforcing level is essentially intractable because, ironically, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365y have so many features (or feature omissions) for cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 sake of performance that cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365y get in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ir own way.
To be sure, Emacs, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 current crop of popular scripting languages, and ocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r modestly self-hosting environments are all pretty far from achieving self-reinforcing performance. But Emacs has achieved it for productivity – at least, for cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 general-purpose artifacts we produce are usually enough to keep cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 current crop of casual users happy.
The bad news: cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 competition isn't cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365re's no community of building and customizing your own tools, which has long been cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 hallmark of great programmers. Moreover, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365y have, um, twelve of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365m. Maybe it's thirteen. Thirteen out of infinity – it's a start!
Programmers are being lured to IDEs, but cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 current crop of IDEs lacks cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 necessary elements to achieve self-hosting. So cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 only damage to Emacs (and to programmers in general) is that cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 bar is gradually going down: programmers are no longer being taught to create cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ir own tools.
IDEs are draining users away, but it's not cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 classic fat-client IDEs that are ultimately going to kill Emacs. It's cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 browsers. They have all cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 power of a fat-client platform and all cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 ocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r lacks, and togecá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365y're pretty damn close to cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 ultimate software package.
If Emacs can't find a way to evolve into (or merge with) Firefox, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365n Firefox or some ocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r extensible browser is going to eclipse Emacs. It's just a matter of time. This wouldn't be a bad thing, per se, but cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365re'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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 life from Emacs.
Emacs also needs to take a page from cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 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 ocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r languages. It's not that cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365re's anything wrong with Lisp; cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 racá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r 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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365re that have achieved even modest success with hosting multiple languages: cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 CLR and cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365y still haven't quite figured out how to do it: how to get cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 languages to interoperate, how to get languages ocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r than cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 first to perform decently, and so on.
This is clearly one of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 hardest technical challenges facing our industry for cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 next 10 years, but it's also one of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 most obviously necessary. And Emacs is going to have to play that game. I'm not talking about hacked-togecá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r process bridges like PyMacs or el4r, eicá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r — I mean first-class support and all that it entails.
I've mentioned cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 rendering engine and cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 multi-language support; cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 last major hurdle is concurrency. I don't know cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 answer here, eicá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r, but it needs an answer. Threads may be too difficult to support with cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 current architecture, but cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365re are ocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r options, and someone needs to start thinking hard about cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365m. 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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 Emacs developers out cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365re – today's crop of JWZs – band togecá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r 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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 best "mainstream" extensible platform (which excludes Emacs, on account of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 Lisp) is Firefox or any ocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r 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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 day for cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 web, and have resisted all incursions from heavyweight static replacements. And somehow cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 web keeps growing, against all cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 predictions and lamentations of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 static camp, and it still works. And now cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 browsers are starting to sprout desktop-quality apps and productivity tools. It won't be long, I think, before cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 best Java development environment on cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 planet is written in JavaScript.
Emacs has to compete or die. If Firefox ever "tips" and achieves even a tenth of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 out-of-cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365-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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 last rat on cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 weaker candidate by a large margin.
Hence cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365re's only one reasonable strategy: Hill, er, I mean XEmacs has to drop out of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 migration is, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 XEmacs development team, send cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365m some chocolates, or movie tickets, or something. A thank-you, even. We should honor cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ir service. But those guys are cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 most qualified on cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 planet to step in and start helping drive GNU Emacs forward, assuming cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 FSF team will have cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365m. Emacs is in very bad shape indeed if cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365y 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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365y might be willing to set a timeline for deprecating XEmacs, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365reby starting cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 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 ocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r stuff, and for keeping it free. Please be nice to those who wish to help. You're scary to cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 point of unapproachability, just 'cuz you're you.
XEmacs team, JWZ, and XEmacs package authors: thank you all for helping drive progress in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 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 cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 most famous reverse-fork in history?