Slashdot Mirror
The Birth of vi
lanc writes "Bill Joy, co-founder of Sun, tells the story of how he wrote the vi editor. The article at The Register delves into his motives, who instigated the project, and some of the quirks of leaving a 'gift to mankind'. From the piece: '9600 baud is faster than you can read. 1200 baud is way slower. So the editor was optimized so that you could edit and feel productive when it was painting slower than you could think. Now that computers are so much faster than you can think, nobody understands this anymore. The people doing Emacs were sitting in labs at MIT with what were essentially fibre-channel links to the host, in contemporary terms. They were working on a PDP-10, which was a huge machine by comparison, with infinitely fast screens. So they could have funny commands with the screen shimmering and all that, and meanwhile, I'm sitting at home in sort of World War II surplus housing at Berkeley with a modem and a terminal that can just barely get the cursor off the bottom line.'"
There's the character level ("C-f"orward, "C-b"ackward), and line level ("C-p"revious line, "C-n"ext line, "C-e"nd of line, "C-a" beginning of line, can't use C-b you see, so might as well use the start of the alphabet). That's when you think of text as rows and columns of characters.
If you think of text as words and paragraphs, then you replace "C"ontrol with "M"eta (which is the Alt key on modern keyboards). "M-f"orward word, "M-b"ackward word, and so on, at least in fundamental mode.
You can also think of text as regions within matching parentheses or other delimiters, then you can use the "M-C" commands (both Meta and Control + some mnemonic key) to move: "M-C-f"orward one expression, "M-C-b"ackward one expression, etc.
What makes all this powerful is that emacs can recognize what kind of file you're editing, then it chooses good defaults for the various levels. So if you're programming in C, when moving around one word at a time, emacs doesn't get confused by the punctuation, and if you like to use something like CamelCase, then there's a minor mode which changes for "M-f"orward and "M-b"ackward word commands so the cursor stops before each hump inside an identifier instead of jumping to the next word.
Unfortunately, emacs has so many commands that there's not enough keys on a keyboard to have simple mnemonics for all the things it can do. That's why we get things like "C-c C-o C-1" in esoteric modes. But if you use specialized modes, the idea is that you should select a key that you like and map the function to it. Usually, the functions keys F1-F12 are completely free to use for anything.
The article has definately triggered some nostalgic moments, but it's an article from September 2003 that reports on the content of an interview conducted in 1999. It isn't really news any longer.
XEmacs isn't the X version of Emacs - it's a completely separate fork.
First, I am totally with you - vi is a MUST for configuring UNIX servers remotely (or even locally) (I want to shoot our sysadmin when he uses nano or pico and "accidently" line-wraps a critical config item).
.foo But for all the effort that goes into writing the configuration API, you might as well embed a micro-web server (there is no language known to man that can't receive a trivial text input, reading only the 1'st line, and spitting out a canned text). It is just as easy (if not easier) to add configuration line-items via a web-form than via a config-file. The reason being, that changes to a properties file usually require restarting or pinging the core app. The micro-web service is directly updating the active operation (and can take whatever steps necessary to perform batch alterations.
"vi"'s defaults are completely oriented towards editing large text config files - better than ANY other editor I've ever seen. emacs often defaults to scrolling past the end of the screen (where you can miss important info if you're not careful). Other editors auto line wrap, or don't properly handle control or windows characters (vi shows nice ^M or whatever symbols). Search-and-replace is fast, and extremely expressive (moreso than any windowed dialog I've ever seen, including [xg]emacs). These are the tools of the sys-admin.
That being said. Remote server management is best "designed" to use a web interface. Any shmuck can design an application that has a foo.properties or foo.conf or
The only remaining elements are buffer-overrun exploits, DOS attacks, authentication... In the UNIX world, you have to be root to edit the config file, so that was considered secure enough. But apache port-80 proxying is commonplace now.. You get all your security up-front. Granted the flaw in my argument is that apache doesn't have web configuration - and probably never will.
Every home-use NAT-box / router I've seen has http interfaces, and that's just dandy for me.
-Michael
> I was going to say the best way to sum them up is that they are both
> ancient [...] relics with arcane "interfaces".
Nobody, so far as I am aware, uses Emacs because of its default interface (which is, indeed, ancient and arcane). We use it because of its capabilities, and we customize the interface to suit our needs. Yes, there are people who *use* the default interface, because they are accustomed to it, because they needed Emacs for its features and never bothered to customize the interface. But they don't use Emacs *because* of the interface.
> Sure, *nix geeks will love it, and they may even devout a surprisingly pathetic
> amount of time mastering it because, "technically speaking, it provides a much
> more robust set of features than any GUI-based program."
You clearly don't understand Emacs.
In the first place, it *is* a GUI-based program. (Yes, you can run it without a GUI, but you would only ever do so if for some reason no GUI is available, and certain features become unavailable under such circumstances; it is certainly not the normal mode of operation.) Second, the amount of time it can save you on a day-to-day basis over a normal text editor editor will pay back your initial learning-time investment in a few weeks, or at most a few months -- at least, it will if you are doing the kind of editing Emacs was designed for.
Emacs is very good for partially automating semi-repetitive tasks. Some tasks can be fully automated, and that's fine, but many editing tasks cannot be automated in that fashion, because the user to constantly make decisions that the software can't handle. Yes, you *could* write an application in Perl or some other language that would repeatedly ask you questions about what to do, but writing it would be tedious and using it would be worse. Emacs, because it embeds and fully integrates the programming language into the text editor, solves these problems much more quickly and easily.
Of course, if you don't perform the kind of editing tasks that Emacs is really good for, then you probably don't care. And if you aren't already a programmer, then learning lisp would be much harder (because you'd have to learn all the programming concepts, in addition to the language) and maybe not worth it. But that doesn't make it any less a valuable tool for those who need it.
A more modern default interface wouldn't hurt it any, I'll grant you. But there is no alternative, currently. There is no tool that can do the things Emacs does, with the ease with which Emacs does them, and has a modern user-friendly default interface. Emacs is the only game in town.
Sure, there are many text-editors. But there are not many *fully* programmable integrated text editing environments -- at least, none that I'm aware of.
Learning to use a bandsaw is a silly waste of time if all you're going to do with it is sharpen pencils. An ordinary pencil sharpener is much easier to learn to use properly, takes up less space, is less dangerous, and will sharpen the pencil just about as quickly. Fine, use the pencil sharpener. But people who make dollhouse furniture are probably going to opt for the bandsaw.
Cut that out, or I will ship you to Norilsk in a box.
Plus you can use vi or emacs in situations where you don't have a GUI available, or on boxes where there isn't much memory to spare, and you'd rather the resources went to GCC than to an X-Server.
Don't let THEM immanentize the Eschaton!
I remember once getting really fooled by this. I'd accidently created a file with two sequential copies of the text I thought I had. I searched for "foobar", which worked as expected; then I searched again. The screen didn't change, and the cursor didn't move. So, first I checked if the mainframe had crashed, but that wasn't it. It took many minutes of fooling around to realize what had happened: EMACS had figured out that the screen already looked right, so no need to do anything (except perhaps update a character or two on the status line). I wonder how many other people had similar experiences back in the day.
So, sure EMACS may have been too big to run fast on Bill's machine, but bandwidth to the terminal had nothing to do with it.
Or more likely 'joe' is a reference to joe, Joe's Own Editor, which has been around since the late eighties. In fact I used it exclusively back when Slackware was distributed on floppies--my temp files were always named bob so I could type 'joe bob' to edit them. Of course this was before I "did the right thing" and switched to vi. :-)
There's no place I can be, since I found Serenity.
One can edit in VI very efficiently without moving the keys from the home position, and doing unnatural stretches for odd keys.
Love many, trust a few, do harm to none.