Everybody "knows" that Emacs is "the best" text editor.

(Actually, in truth anybody who *knows* about such things would know 
that Emacs isn't a text editor at all. It's an elisp interpreter that 
comes with a text editor application preloaded. :-P )

The more vocal proponents will tell you how Emacs is the most advanced, 
sophisticated, powerful and generally /perfect/ piece of software that 
Mankind has ever produced, and that no other editor could ever come 
close to equalling its supreme perfection. And yet, none of them can 
explain /why/ it's so perfect. (Except that, hey, you can *customise* it!)

Actually, you know what? That sounds rather like Lisp. Everybody "knows" 
that Lisp is the most powerful, most perfect language, but nobody can 
explain why. Except that "everything is data", so you can write PROGRAMS 
that write PROGRAMS!

Obviously, in spite of all the fanboys, practically nobody actually uses 
Lisp, and as best as I can tell, nobody uses Emacs either. (For 
sufficiently large values of "nobody".) So clearly these are sound 
arguments. :-P

Once upon a time, I did sit down and try to learn Lisp. What I found was 
a language with a simple and reasonably elegant idea, then swiftly 
buried under several miles of clutter and junk. No thanks.

Suffice it to say, I /still/ don't get why anyone would want to use 
Lisp. But hey, whatever.



I'm curious to know in which sense Emacs is "the best".

Is it "the best" in the same way the Lisp is "the best"? In other words, 
"everybody knows" it's the best, but nobody can actually explain why, 
and nobody actually uses it.

Or perhaps it's "the best" in the same way as Eiffel. Basically Eiffel 
is the ultimate, most perfect OO language. That's what it was designed 
to be, from the ground up. It's the most perfect embodiment of the OO 
paradigm. (Although they also tacked on Design By Contract, which isn't 
strictly anything to do with OO.) A perfect language... shame the 
implementation sucks arse, eh?

Maybe it's "the best" in the same way as TeX. The output of TeX is quite 
simply the most beautiful thing I've ever seen. Nothing else even comes 
remotely close to looking this damned good. Which is just as well, 
because otherwise TeX would have been nuked from space long ago. The 
/output/ is delightful. The /input/ is the stuff of nightmares. For TeX 
is basically a PDP-era text macro expansion system which also houses a 
sophisticated constraint-solver for typesetting text. It really doesn't 
handle colour, it really doesn't handle images, and it most certainly 
does /not/ handle styling or customisation of any kind! Oh, and don't 
try debugging it.

Maybe it's "the best" in the same way that C is "the best". Everybody 
knows it's dangerous, unreliable and difficult to use. But everybody 
uses it because everybody /else/ uses it.

Or perhaps it's "the best" in the same way that Unix is: It's ancient 
and basically obsolete, but nothing can match it for reliability, 
flexibility and compatibility with a large library of existing stuff.



Having sparked my interest, I decided to go find out about Emacs, to see 
if I could discover what's so damned special about it. I began at the 
GNU Emacs web page. Within about 4 mouse clicks, I came across the 
phrase "VT100".

No, I am not kidding. Just skimming the introductory text, already I'm 
finding references to 40-year old technology. Then again, ASCII is 
pretty ancient, yet still relevant. The VT100 itself may be long 
obsolete, but the protocol it speaks has become something of a de facto 
standard for terminal emulators.

Then again, only Unix nerds use terminal emulators. The rest of us, here 
in the second decade of the twenty first century, have moved on a tad 
from that. :-P

Suffice it to say, Emacs is /ancient/. From what I can gather, it's even 
older than Unix - if that's actually physically possible. As tools go, 
comparing Emacs to my current text editor is like comparing a electric 
microwave oven to a paleolithic flint axe. We're really talking about 
the most distant aeons of computing prehistory, almost from before 
computers were computers. (Unit record equipment, anyone?)

Directly because of this, the introductory material uses strange phrases 
like "if your keyboard has a backspace key"... What do you mean *if*? 
It's only been there for, like, over two decades. :-P Similarly, suffice 
it to say that Emacs does /not/ follow any remotely modern standard for 
normal keyboard commands. They simply didn't exist when Emacs was written.

Even the terminology is all wrong. Cut & past are called kill & yank. 
(Even though those sound like synonyms, they are in fact inverses of 
each other.) Except that... no, not really, no. Kill and yank are 
/similar/ to cut and paste... but not quite. Oh, and there's no copy.

Everything is like this. "Load" is called "find". Except that, again, no 
it isn't quite the same. Because "find" is also for switching between 
buffers. There is no "new"; instead you must "find" a non-existent file, 
type some stuff, and then save it. As best as I can tell, it is 
impossible to save an existing file under a new name. (I.e., there is no 
"save as".)

Similarly, the cursor isn't called a cursor, it's called "point". The 
status bar isn't called a status bar, it's called a "mode line". Loading 
a file is called "visiting" it. The list goes on.

Given that the major "feature" of Emacs is that it's completely 
configurable, I'm interested to see how easy it is to actually configure 
it. My editor of choice is SciTE, which has quite a lot of configuration 
options. Unfortunately, that means that after you download it, you have 
to spend about three weeks configuring all the stupid defaults to more 
sensible settings. It takes so damned long that I actually find it worth 
while transporting the configuration settings from machine to machine.

Also, given that it apparently has billions of commands, I'm curious to 
know how you map all these things to the keyboard. Without getting into 
a long keyboard vs mouse debate, both have their advantages.

I think it was Warp who mentioned a while back how every film and TV 
program you'll ever see always shows the ultra-hacker frantically typing 
away on his computer as stuff appears on the screen. And yet, very 
little software can actually be controlled from the keyboard like that. 
It occurs to me that one program which /can/ is FractInt.

Once you get to know FractInt (i.e., once you've wasted several years of 
your life experimenting with the several hundred fractal types, options, 
bells, whistles and doodads it offers), you can use the keyboard to 
control it astonishingly fast. Each sub-menu and command is basically 
one keystroke, and you end up casually typing three or four keystrokes 
at once without really having to think about it, such that screens zip 
past faster than the eye can see, and the program is reconfigured.

Then again, FractInt is about drawing pictures. You hardly ever need to 
type in text. Emacs is a /text editor/. Typing in text is kind of THE 
ENTIRE REASON IT EXISTS. So I wonder how well you can control it from a 
keyboard?



And then, on Wednesday morning, I did possibly the nerdiest thing I've 
ever done in my entire life: I installed (GNU) Emacs. On Windows XP. Yah.

So how do you install it? Well, you go to the website, download a zip 
file, and unzip it. You then execute runemacs.exe, and a window opens. 
I'm rather fond of programs which are this easy to set up.

OK, so what does it look like? Well, it's fairly ugly. Not the worst 
I've ever seen (e.g., gnuplot is just awful), but it's obviously FOSS. 
You can tell by the big logo utterly lacking antialiasing, the ugly 
fonts in inconsistent styles and sizes, the thoughtless gaudy colour 
scheme, and the grab poorly drawn icons with far too much empty space 
around them.

Aside from that... it looks pretty normal. It's got a menu bar and a 
toolbar at the top, a status bar at the bottom, and a scrollbar on the 
side. Now on a normal status bar, the various status elements are 
separated by actual *graphics*, whereas Emacs is using some lame ASCII 
art to do the same job. That looks kinda tacky. But so far, that's about 
the only difference.

So I click on "Emacs tutorial" and start reading. Heh, apparently Emacs 
predates thinks like cursor control keys. Rather than Page Up and Page 
Down, it directs me to use Ctrl+V and Alt+V. And rather than arrow keys, 
we have Ctrl+N ("next"), Ctrl+P ("prev"), Ctrl+F ("forward") and Ctrl+B 
("backward") for cursor movement. In place of Home and End, we have 
Ctrl+E ("end") and Ctrl+A ("aahhh... wuh??").

Interestingly, while Ctrl+F moves the cursor one character forward, 
Alt+F moves it one /word/ forward. (And similarly for Ctrl+B vs Alt+B.) 
I've never seen a text editor that can do that. (But then again, it's 
not exactly a feature you'd bother looking for.) I'm kinda curious as to 
what Emacs considers to be a "word", but as best as I can tell be 
experiment, it just moves the cursor to the next non-alphabetic character.

In a similar way, Alt+A and Alt+E move by "sentence". Again, not sure 
how Emacs decides what constitutes a sentence. It seems to be going by 
punctuation or by line ends or something.

Fortunately, it turns out that the arrow keys and the scroll bar both 
work just fine, so I don't actually need to remember any of this 
nonsense. Oh, except... the scroll bar has a quirk. Scrolling the view 
actually moves the cursor. It can never be scrolled off the screen. 
(Presumably because on a VT100 there's no way to turn off the cursor. :-P )

This annoying quirk means I can't use one of my favourite editing 
behaviours: If I'm editing line 700, and I want to check something on 
line 300, I can leave the cursor on line 700, scroll up to line 300, 
look at what I want, and then when I start typing, the view instantly 
snaps back to line 700 (so I don't have to hunt around for it). On the 
other hand, the documentation suggests that you can have more than one 
view of the same buffer open at once, and if that's actually true it 
would be even /better/...

What's that? I can move to the top of the file with "M+<"? Oh, perhaps 
you mean "Shift+Alt+,"? :-P Interestingly, by this point, I'm rapidly 
discovering that using the Alt key is surprisingly uncomfortable. :-/ I 
wonder how come I never noticed this fact before?

Apparently by typing Ctrl+U 8 Ctrl+F, I can move the cursor exactly 8 
characters left. I'm left wondering why in the name of God I would 
*ever* want to do this. Still, I guess there might be other commands 
where the numeric prefix is actually useful for something. I 
particularly like the way that typing Ctrl+U gives absolutely no visual 
indication at all that something just happened, as per good HCI design 
guidelines.

LOL @ inaccurate description of how a scrollbar works.

There's a section on "when Emacs is hung". What, you're actually 
expecting that to happen? Maybe I need another editor. o_O In fact, it 
turns out what it /really/ tells you is that Ctrl+G cancels a command. OK.

Finally we come to the part about how to actually /edit text/. (Hey, I 
guess a text /editor/ is also a text /viewer/, right?) After four 
paragraphs explaining what "backspace" is and what to do if you don't 
have one (??!), it tells you how Emacs handles lines too long to fit on 
the display. Oh, that's nice. It wraps it for you and puts little 
markers there to tell you it's wrapped. That's how I usually configure 
my editor. On the other hand, it wraps characters, not words. *sigh*

I quickly discover that, say, Ctrl+K deletes (sorry, cuts) all the text 
from here to the end of the line. But the usual approach of positioning 
the cursor, holding Shift, and then repositioning the cursor doesn't 
select text. It works if you drag with the mouse, but doesn't work at 
all with the keyboard.

As best as I can tell from the documentation I've seen, as well as 
"point" there is also "mark", and you use this to delineate regions (for 
deletion or whatever). You also use it to return to the place where you 
last were. (So, no possibility for confusion there then.) Oh, and 
there's one "point" per window, but only one "mark" per buffer. Nice 
symmetry there! >_<

Also, you can't see the mark. Only the point. Again, I'm guessing this 
is a limitation of the obsolete VT100 technology on which Emacs appears 
to be fundamentally based. Never mind that 40 years later, we have 
raster graphics terminals capable of displaying arbitrary graphics. No 
sir, ANSI escapes for me!

Trying to wrap my head around the exact semantics of killing, yanking, 
the kill ring, the mark and point, and so on is pretty damned hard. I 
suppose if I persevere I'll get it eventually. The undo concept is 
similarly baffling.

What particularly strikes me is that a rare operation such as moving 
forward one word is given a fairly short key sequence (Alt+F), but a 
common operation like undo gets a comparatively long one (Ctrl+X U). The 
documentation helpfully mentions that you can use "Ctrl+_" instead. 
Except that "_" is "Shift+-", so what you're actually saying here is 
"Shift+Ctrl+-". Yeah, that's much easier. :-P

Ooo, now it starts talking about how to load and save files. Because, 
you know, that's kind of crucial too. (In fairness, without cursor 
movement, you can't actually read the tutorial!)

Now, get this: Apparently a very rare operation such as "search" is 
Ctrl+S, but an extremely common operation like "save" (arguably the 
single most important command that any file editor can ever have) is 
Ctrl+X Ctrl+S. Quite apart from the fact that this clashes with modern 
usage (which arguably is no fault of Emacs), why is a highly specialised 
and uncommon operation like searching given a fast direct-access 
command, and the infinitely more common operation of saving your work 
requires two key presses in the correct order?

Also, as I say, you can't just say "new file". You have to actually 
specify the full name and path first. Apparently the only way to get a 
file dialogue to open is to use the mouse. Sure, the minibuffer prompt 
has tab-completion, which is arguably faster. Some visual feedback would 
still be nice though. (You can get that if you press Tab twice. But then 
you have even more buffers open...)

I notice that Ctrl+X Ctrl+S saves the current file, while Ctrl+X S 
/asks/ you whether to save the current file. I've noticed similar 
behaviour with a couple of other commands. (Not that this seems to be 
mentioned anywhere...)

Emacs allows you to have multiple files open at once. The standard way 
to switch the current view to another file is to "find" the file - i.e., 
do what you'd do in order to open it in the first place. Fortunately, 
the GUI provides a menu that shows you what buffers exist and lets you 
switch to them, without the extreme clunkiness of the various switching 
commands. (E.g., list available buffers, change window, select the 
buffer you want, close that other buffer...)

I notice that the window titlebar provides no indication of what file 
you're editing. (It just says "Emacs" and then the DNS name of the PC. 
Yeah, that's very useful information. :-P ) Only by actually looking at 
the Emacs window can you see this. Oh, and if you have several buffers 
visible, the buffer name is at the /bottom/ of the display, not the top 
where you would logically expect to find it. Great!

I also notice that the buffer name "is the same as the file name, 
without the directory part". Great. Let's hope I never have to edit half 
a dozen files all named Desktop.ini or something... Oh, wait.

Earlier I was wondering how Emacs maps all its millions of commands to 
the keyboard. Apparently the answer is that the most common commands get 
a Ctrl or Alt sequence, less common ones are Ctrl+X and then something, 
and the leave common ones of all are Alt+X followed by typing in a 
command name.

...which seems reasonable, although some of their decisions about what 
constitutes "common commands" are /highly/ dubious! It's kinda neat how 
the command name prompt does tab completion without needing tab though.

LOL @ the bit about using Ctrl+Z to temporarily take the terminal back 
to the shell. No deary, see, in this modern age, we don't use 
/terminals/ any more. We have *real* computer displays. :-P

LOLRUS: Pressing Ctrl+Z actually minimises the Emacs window! :-D So I 
guess it does still have a use.

Having tried the incremental search I discovered something quite nice: 
it actually /highlights/ everything on the page that matches your 
search. A trivial feature, but one which I haven't seen in any other 
software. It's also kind neat how jabbing the search keys takes you to 
the next or previous match. OTOH, once you exit search, the search term 
is gone forever, in contrast to modern editors.

Ever since I started this tutorial, I've been looking at the 
70-character text down one side of my enormous widescreen monitor, 
trying to figure out how to add more windows. To my frustration, every 
command that creates a new window splits the display /vertically/, not 
horizontally. (Still, at least you can drag it with the mouse, eh?)

Eventually I discover that the command in question is Ctrl+X 3. 
(Obviously...) I also discover that you can only drag the divider if you 
point at exactly one part of it, in contrast to the horizontal dividers 
which can be grabbed anywhere.

The documentation also claims that if you middle-click on either the 
status bar or the scrollbar while holding Ctrl (um, why?) it splits the 
window. Clicking the status bar /does/ work, but clicking the scrollbar 
does /not/ work. (The minibuffer even pops up a message to tell you that 
this action is not defined.) Score another one for accurate 
documentation. (Remember, I just got this out of the box.)

It's a nice touch that Ctrl+Alt+V scrolls the /other/ window. I guess. I 
mean, if it weren't so trivial to do it by hand anyway.



OK, so pretty much one of the "killer features" of Emacs is supposed to 
be syntax highlighting. So how does it work? I proceed to open a random 
selection of files, and sure enough, their syntax is highlighted in 
various ways.

The whole idea of major modes and minor modes is interesting and all. 
But what happens if, say, I have JavaScript embedded in HTML? If I open 
a JavaScript file, it correctly colours the listing. If I open an HTML 
file, same deal. But if I open an HTML file that contains JavaScript... 
nothing happens. The HTML is recognised, the JavaScript isn't. So here 
is where Emacs fails, and SciTE succeeds.

The HTML highlighting is actually nicer than most. Usually you just get 
the actual markup elements highlighted; Emacs goes that step further, 
simulating certain aspects of the formatting. For example, section 
headings appear bold and underlined, making quickly scanning through the 
markup for that section heading much easier. That's a nice touch. Bits 
marked with <i> or <em> actually come out italic. (Which is admittedly 
kind of ugly with a typewriter font.) Just a few details like that.

It's not very obvious unless you know to look for it, but all the menus 
change when you open various kinds of files. That's nice. (The command 
for "open a browser and display this page" is a bit buried, but it's there.)

There's a whole bunch of annoyances so far. Emacs gives you a vertical 
scrollbar, but no horizontal one. The horizontal commands listed in the 
command reference don't appear to work at all. The vertical scrollbar 
behaves incorrectly (it sometimes scrolls past the end of the file). 
There's a minor mode that wraps text as you type - by word - but only 
after you *finish* typing, which is no good at all. (Thunderbird manages 
to do this completely interactively. It even draws a line to show you 
how much width you have to play with.)



In short, after spending a few days playing with Emacs, I'm still not 
finding anything that makes me to "wow!" Yes, it has a tetris 
implementation. And yes, it's the ugliest, least entertaining tetris 
you've ever seen in your life. Big deal.

Perhaps if I spent a few years reconfiguring Emacs, I could make it more 
to my liking. But I doubt it. In some ways, it's like Unix. Oh, sure, a 
modern Linux distro has lots of shiny eye-candy. But underneath all 
that, it's still the same kludge hodge-podge of ancient software that it 
always has been, and always will be.

Don't believe me? mgetty. "Modem-aware get TTY". That's TTY as in 
teletypewriter. Still think Unix is part of the modern era?

Emacs is obviously /trying/ to be a modern application. Trouble is, 
every step you take to make it more modern is also a step that makes it 
less compatible with all the old cruft written for it - which is half 
the benefit of using it in the first place.

Emacs is trying to pretend that it's a modern GUI application. But take 
more than a casual glance and the truth shows through. Don't get me 
wrong; I'm sure there was a time when being able to see multiple windows 
on the same green screen connected to a modem communicating with a 
lumbering mainframe somewhere has a major technical achievement. Today I 
just find myself irked that I can't freely move windows around like I 
can with the rest of my desktop.

Sure, you can drag the window edges. But there's no way to create new 
windows or close existing ones with the mouse. Nor is there a quick and 
easy way to switch the view of one window. (You have to click on that 
window and then go to the menu to select which buffer you want it to 
display.) You can't swap two windows around just by dragging them. 
Instead you have to find out what buffer each one displays, and then 
switch buffer on each window, one at a time.

You can make the final display look like anything you want. It's just so 
much /hassle/ to get there. In a real GUI program, this stuff is all 
trivial.

Emacs can view info pages. Again, once upon a time, a program that 
allows you to view its own documentation might have been considered 
radical and revolutionary. Today I just find myself shrieking "why can't 
I open this link in a new tab?!" (And answer, apparently, is that you 
have to create a new info buffer, navigate to the same place on that, 
and then click the link in question in /that/ buffer.) Oh, I'm sure if 
you know Lisp you could code up something that does exactly what you 
want... or you could just use an editor which already includes this 
trivial functionality out of the box.

One of the interesting things stated in the documentation is that Emacs 
supposedly lets you use its full text editing capabilities on things 
over than file contents. For example, Emacs can display a directory 
listing, and if you do a find and replace on it, that effectively 
implements a batch rename operation.

Nice idea, but... Well, treating something structured like that as flat 
text seems wrong to me. For example, what if you wanted to rename all 
the files name frame25 (or whatever) to F25, but the frame files happen 
to be owned by a user called frameserver. Would the owner name also get 
changed to fserver? Because that would be /bad/...

In truth, while I didn't try this particular experiment, I found the 
dired mode to be utterly excruciating to use. It's just too clumsy. I'm 
using to being able to effortlessly explore the system. With this thing, 
I'm not even sure where I *am*. (Tree views exist /for a reason/, as do 
full file paths.) Here again, the terminal heritage shows through; 
rather than nice graphics to indicate structure, we get ASCII art.

I suspect you could probably make something /like/ Emacs, but with a 
modern design, and it would work well. But Emacs itself just looks old, 
klunky and irrelevant to me.

Post a reply to this message