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

On 4-8-2011 17:02, Invisible wrote:

I'll leave correcting you on several EMACS mistakes to the others. I 
just want to point out that you apparently have been looking at an 
*implementation* (under windows?). You should not confuse that with the 
/idea/ EMACS.

But with regards to TeX or LaTeX

> 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.

It isn't. It is more straightforward than e.g. Word. Everything you need 
to know is in plain sight.

> 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 does. No idea how you got that impression.

> it really doesn't handle images,

It does. No idea how you got that impression.

> and it most certainly
> does /not/ handle styling or customisation of any kind!

It most certainly does. Style files are are at the heart of the system. 
As a small comparison: a friend of mine had written her thesis in Word, 
after her text was accepted by the committee she needed 3 weeks of hard 
work to convert it from an A4 draft version into a paperback format text 
that she could submit to the printer. I did it, with the help of a 
student, in one evening. And I had different layouts for chapters 
depending on whether it was published before or not.

> Oh, and don't try debugging it.

If you want to debug TeX, that is relatively easy, all sources are 
available, documented and even published as a book 
(http://www.amazon.com/Computers-Typesetting-B-TeX-Program/dp/0201134373/). 
Moreover Don Knuth has a reward for anybody finding a bug.

If you mean debugging your text or layout, that is more simple than in a 
wysiwyg editor.

If you mean debugging style files or bibstyle files you are correct, 
that is a nightmare if you don't know what you are doing. Simple advise: 
don't touch them.


-- 
Apparently you can afford your own dictator for less than 10 cents per 
citizen per day.

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> 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!)

  It's things like this: http://www.youtube.com/watch?v=EQAd41VAXWo

  (As for the rest of your post, tl;dr, sorry.)

-- 
                                                          - Warp

Post a reply to this message

On 8/4/2011 8:02, Invisible wrote:
> 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.

Well, that's what happens when you take something that has evolved in 
several different directions for a few years, then mushed it back together.

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

You want to learn Forth?  Here's what you can do with Forth:

http://www.reddit.com/r/programming/comments/iyb2d/freeform_a_meta_language_that_allows_defining_and/c27ojnx

> (Although they also tacked on Design By Contract, which isn't strictly
> anything to do with OO.)

If you didn't understand why DbC is fundamental to "perfect" OOP, you've 
missed a major point of the development of it. DbC *is* the OO. The actual 
bodies of the methods are an implementation detail. :-)

> A perfect language... shame the implementation sucks arse, eh?

True. The first time I tried it, and this is like version 5.2 or so, you 
started a new project and it gave you a Hello World skeleton to start from. 
If you started a new project, then clicked "compile" without touching 
anything else, the compiler bombed out.

> 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.

Hopefully they've improved it. TeX is probably OK as long as you don't use 
it with metafont files, but the output with metafont is pretty sucky.

> 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.

I'd argue that Windows may have better flexibility (modulo not actually 
having the source to it, and not counting "portability" as "flexibility") 
and a larger library. It's certainly not a slam dunk for Unix. Plus, Unix 
isn't really all that reliable, either.

> Suffice it to say, Emacs is /ancient/. From what I can gather, it's even
> older than Unix

The first versions were. I don't think it was called emacs at the time. It 
was also originally developed on an OS other than Unix, so the "meta" key 
was actually a separate key from "alt".

> Similarly, the cursor isn't called a cursor, it's called "point".

The two are different things. The point is where text is inserted. The 
cursor is an indication on the screen.  The two aren't necessarily the same 
thing.

> Ctrl+A ("aahhh... wuh??").

Because Ctrl-H is help, you see.

That's the thing that always killed *me* about Emacs. The key mappings were 
half mnemonic and half abbreviation and half based on keyboard position. On 
the other hand, Wordstar I still remember every keystroke, in spite of not 
having used it since 1982 or so.

> 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.

Really? Even notepad does that: ctrl-rightarrow. Every editor does this.

 > (But then again, it's not exactly a feature you'd bother looking for.)

Of course it is, especially if you're editing text.

> 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.

It depends on the mode. A "word" is one token.

> 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.

Again, it depends on the mode. If you're editing a program, it's one 
statement, one s-expr, etc.

> (Presumably because on a
> VT100 there's no way to turn off the cursor. :-P )

No, it's because VT100s don't have scrollbars. Emacs didn't have scrollbars 
until after windowed operating systems with scroll bars were common. Heck, I 
suspect emacs predates the invention of the scroll bar.

> 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.

Because you want to draw a line of 30 hyphens across the screen. Or you want 
to skip to line 287 in your file.

> There's a section on "when Emacs is hung". What, you're actually expecting
> that to happen?

If you're writing your own code, or you hand it a few megabytes and say "go 
indent this".

> 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.

I'm not sure why you think you'd save a file more often than you search. It 
boggles my mind to think you think searching for text in a file is highly 
specialized and uncommon.  Oh, wait, this from the guy who doesn't use 
google. ;-)


> 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!

Again, you're cutting on emacs for being a program written and popular 
before windowing OSes were common? Before the Mac and MSWindows established 
the standards of title bars and scroll bars and where status lines go and 
what they're called?

> ...which seems reasonable, although some of their decisions about what
> constitutes "common commands" are /highly/ dubious!

That's why you can remap the keys as you like. ;-)

> 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.

Damn, man, you gotta get out more. I haven't seen any decent editor since 
Win95 that doesn't do that. Sure, not notepad, but everything else.

> 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.

Nobody uber enough to use emacs would stoop to editing web pages with 
embedded javascript. ;-)

Really, the code that recognises that stuff just needs to be updated.

> The HTML highlighting is actually nicer than most.

You should check out VIM if you want a somewhat more rational editor that 
does all this stuff emacs does.

> 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.

Many of the nice features of emacs become redundant in an environment with 
windows, and especially in an environment with IDEs customised for the 
specific languages you're using.

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

Sadly, Unix *is* part of the modern era, because we are still doing things 
like we did in 1970.

> 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.

Me, I usually use VIM, and open each VIM in a separate window. If you 
actually want to do emacs-y like stuff, like run the compiler over the 
buffer that you just typed, and then write code to jump from error number to 
error number in your source code, I expect that would be much more difficult 
with emacs.

> I suspect you could probably make something /like/ Emacs, but with a modern
> design, and it would work well.

Yes. They call it an IDE. ;-)  Or "a windowed desktop."

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message

On 8/4/2011 8:45, andrel wrote:
> It does. No idea how you got that impression.
> It does. No idea how you got that impression.

The original versions didn't. It has probably been added to. It certainly 
didn't when I used it for my thesis.

> small comparison: a friend of mine had written her thesis in Word,

Did she use styles in Word? I suspect not.

> And I had different layouts for chapters depending on whether it
> was published before or not.

You can do that in Word also, ya know. You just have to use styles from the 
start, instead of trying to plug them in after the fact. Just like TeX.

> If you mean debugging style files or bibstyle files you are correct, that is
> a nightmare if you don't know what you are doing. Simple advise: don't touch
> them.

"Why does it insist on putting the images at the top of the next page 
instead of the bottom of the page where I include it?"

"Because Leslie likes it that way."

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message

On 8/4/2011 8:48, Warp wrote:
> Invisible<voi### [at] devnull>  wrote:
>> 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!)
>
>    It's things like this: http://www.youtube.com/watch?v=EQAd41VAXWo

Yes, my editor can do that. Indeed, it can even take that bunch of text and 
export the table to an actual SQL server.  It's exactly that sort of stuff 
that keeps corporations buying Word instead of OpenOffice.

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> >    It's things like this: http://www.youtube.com/watch?v=EQAd41VAXWo

> Yes, my editor can do that. Indeed, it can even take that bunch of text and 
> export the table to an actual SQL server.  It's exactly that sort of stuff 
> that keeps corporations buying Word instead of OpenOffice.

  Can you do it in a text terminal through ssh? Can you customize the
functionality, change it, add new features or modify existing ones? Can
you run it on Windows, Linux, MacOS X, BSD, Solaris, and basically any
Unix-style OS in existence? Can you get that software for free?

  I didn't think so.

-- 
                                                          - Warp

Post a reply to this message

On 4-8-2011 18:08, Darren New wrote:
> On 8/4/2011 8:45, andrel wrote:
>> It does. No idea how you got that impression.
>> It does. No idea how you got that impression.
>
> The original versions didn't. It has probably been added to. It
> certainly didn't when I used it for my thesis.

If this is about color, it might indeed have been added later. What I am 
using now does support it. Note that the source of TeX has been stable 
for a long time, so it probably was possible earlier, but only supported 
when there was a sort of generalized output format (or input format for 
the printing device, depending on your POV).

>> small comparison: a friend of mine had written her thesis in Word,
>
> Did she use styles in Word? I suspect not.

I guess she didn't and it was more than a decade ago (as was mine)

>
>> And I had different layouts for chapters depending on whether it
>> was published before or not.
>
> You can do that in Word also, ya know. You just have to use styles from
> the start, instead of trying to plug them in after the fact. Just like TeX.

I know.

> "Why does it insist on putting the images at the top of the next page
> instead of the bottom of the page where I include it?"

You can put them elsewhere, but it indeed is sometimes a fight.

OTOH so is it in Word. When I write a short 4 paper abstract in Word 
(for some reason the norm for biomedical engineering conferences) 
getting the layout right takes more time than writing. Not the initial 
layout, but every time someone edits a piece of text, and again after it 
was transported between various versions of Word and/or open office etc. 
Often it is more simple to do the complete layout yourself by adding 
linefeeds <shudders> than by using the template provided by the 
organization. For some reason they often also want to have the original 
*.doc file for inclusion in the abstract book. So I can not escape to 
something better.



-- 
Apparently you can afford your own dictator for less than 10 cents per 
citizen per day.

Post a reply to this message

On 8/4/2011 9:28, andrel wrote:
> If this is about color, it might indeed have been added later. What I am
> using now does support it.

Neither color nor images were supported by TeX in 1991 when I used it for my 
thesis.

> there was a sort of generalized output format (or input format for the
> printing device, depending on your POV).

Well, more like only supported when there was a post-processor to put the 
images into the empty spots TeX left for them, and only supported when color 
printers were common. :-)

> OTOH so is it in Word.

Yep. I was just commenting that TeX and LaTeX aren't really simple enough 
that you can make them do what you want with ease.

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message

On 8/4/2011 9:22, Warp wrote:
>    Can you do it in a text terminal through ssh?

Why the hell would I do that? I can run it remotely in a variety of ways, 
but no, not in a text terminal.

Can emacs run on a hardcopy terminal?

> Can you customize the
> functionality, change it, add new features or modify existing ones?

Yep. Heck, at this point, I can program it in C# instead of elisp. I can 
also trivially connect it to and incorporate anything else that has a COM or 
.NET scripting interface under Windows, including remoting it to other 
processors on the network, in order to extend its functionality. It's messes 
like that that make it popular - the fact that the average business user can 
get something custom done without going thru the IT department.

> Can
> you run it on Windows, Linux, MacOS X, BSD, Solaris, and basically any
> Unix-style OS in existence? Can you get that software for free?

That wasn't the question, tho. The question the video asked is "can your 
text editor do this" and then showed embedding a spreadsheet into a text 
document and regenerating HTML from that. And the answer is "yes, my text 
editor can do that." I mean, come on, they're showing off that they can put 
columns in a text file that adjust to the width of the text in the column? 
Yes, indeed, my text editor can do that.

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message