EMACS ¶Ô vi£ºÓÀÎÞÖ¹¾³µÄÊ¥Õ½

¹²ÓÐ 6 ÌõÆÀÂÛ

1. 594chengzhi ÓÚ 2010-04-12 23:40:05·¢±í:

   ÎÒ»¹ÊÇѧemacs°É¡£¡£

2. renddie ÓÚ 2009-07-27 02:02:26·¢±í:

   Áõ³å³öÆ·£¬±ØÊô¾«Æ·

3. l460618498 ÓÚ 2009-07-26 22:25:51·¢±í:

   ¼ÈÓÐÓ¢ÎÄÓÖÓкºÓïµÄ°¡

4. Áõ³å ÓÚ 2009-07-26 21:40:44·¢±í:

   ÒýÓÃ:

   ÒÔÇ°¿´¹ý£¬²»´í²»´í~~
   СÆÕÁÖ˹ ·¢±íÓÚ 2009-7-26 21:27

   ÁÖÃÃÃ𡣡:0wioe(1

5. СÆÕÁÖ˹ ÓÚ 2009-07-26 21:27:09·¢±í:

   ÒÔÇ°¿´¹ý£¬²»´í²»´í~~

6. Áõ³å ÓÚ 2009-07-26 21:20:43·¢±í:

   EMACS vs. vi: The endless geek 'holy war'
   By Joab Jackson on December 04, 2001 (8:00:00 AM)
   
   Share Print Comments
   
   There they went, at it again. The president of our local Linux user's group sent out the word that the week's tutorial would be canceled. That the tutorial was on using the vi text editor was enough to set off a fresh round of sniping.
   
   Greg Menke fired the first salvo. Use vi? How hard could that be? He emailed his own steps for using vi. They were, as follows:
   
   1. Procure fish, any kind, length > 12 inches
   2. Freeze it overnight
   3. Sit in front of PC, run vi
   4. Holding fish by the tail, smash it repeatedly against your forehead until you decide to give EMACS a try because the fish scales are flying around your head and it's starting to ache.
   
   Menke, of course, was implying that not only vi was insanely obstinate but that vi users were obstinate as well for refusing to admit how they were inflicting upon themselves frozen-fish-against-the-noggin levels of brutalization.
   
   It didn't take long for vi lovers return fire. One suggested Menke add this line to his instructions: "Type 'emacs' before step 1, so that by the time step 4 is done, it will have finally finished loading."
   
   Now, was he trying to say the EMACS text editor was slow?
   
   Like fight-fatigued battalions who come to a temporary truce but refuse to give up the war, vi and EMACS users keep an uneasy standoff in many Linux, SAGE and other computer-related virtual communities. It's the kind of standoff that may remain dormant for months, but it takes only the vaguest slight from one side for the flames to roil across the newsgroups and mailing lists once again. For just beneath their civil demeanors, each camp feels the editor they use is the best of all possible editors and those who use any other editor, particularly that other editor, are fools who would realize the error in their thinking if only pounded with enough mockery.
   
   Now, a rift over which Unix text editor is God's Own Build may not seem significant given all the troubles of the world, a Coke vs. Pepsi standoff of no consequence, no motivator beyond simple group bonding ("Go Team!").
   
   But why has this difference of views remained a divisor of programmer culture for more than two decades now? Why has it remained intact as the PC, graphical user interfaces, the mouse, the Internet and Open Source each altered the computation landscape?
   
   "As far back I can remember both, the hacker population has been split 50/50 [between] EMACS [and] vi," emails Eric Raymond, who counts as many of his roles in the Open Source software and hacker communities as a long-time observer/participant anthropologist. "Pico, joe, MicroEmacs, and other editors have basically been down in the statistical noise during the whole period." Raymond can personally date the vi/EMACS split back to 1985 and stipulates that, in all likelihood, it went on long before that.
   
   As early as 1991, Raymond recorded the vi vs. EMACS "holy war" in the Jargon File, perhaps the ultimate collection of hacker terminology.
   
   When pressed, most people familiar with both editors will say the difference between the two is one of speed vs. flexibility, with vi users pointing to how darn quickly they can move around and EMACS lovers touting their immense number of options. Vi users deride EMACS for being unnecessarily ostentatious; EMACS users derided vi for being difficult to learn and limited in scope.
   
   So the great text editor debate of our time comes down to the technical equivalent of "tastes great/less filling?" Well, yes, kind of. But like with all matters of religion -- or war -- the deeper you dig, the murkier the issues get.
   
   But there is significance here. These editors are the tabula rasa upon which much of cyberspace has been built. That these tools, each designed to be transparent to the end user, are subject to such fierce and competing loyalties, reveals something about some primordial assumptions people have about the best ways of getting things done.
   
   Vi: The editor that time forgot?
   
   At first glance, outsiders might see vi as the editor that time forgot. It's not just that you have to open up a terminal window just to use the thing. That's the best way to get to EMACS, too. But even with the VIM, the updated version most vi users employ these days, one can't help but to marvel at (or become frustrated over) the sheer lack of intuitiveness of how it works.
   
   Even the webmaster of the VI Lovers Home Page admits that the learning curve is steep. "Vi doesn't get fast before you know 25 commands or so," wrote Amsterdam native Thomer Gil, now working on a computer science Ph.d. at the Massachusetts Institute of Technology.
   
   Gil's been likened by his office-mates to a "caveman wielding ax and club" for his use of VIM.
   
   Of all vi's perceived shortcomings, perhaps the most noticeable is how you need to toggle the insert key just to type anything onto the screen. Vi has two modes: One is the "insert" mode where you can enter text. You get to that mode by hitting the "insert" key on the keyboard. But there is also the command mode where you can't enter text, but instead enter relevant commands. From insert mode, you can get there by hitting the escape key.
   
   So imagine the unsuspecting first-time user typing away who accidentally hits the escape key, only to find that not only can he longer enter text, but his keystrokes are sending the program in strange directions.
   
   The Jargon File dryly notes that this feature of vi "tends to frustrate new users no end, as it will neither take commands while expecting input text nor vice versa, and the default setup provides no indication of which mode the editor is in."
   
   "Multiple modes freak people out," Gil admits.
   
   Vi was written by Bill Joy in 1976, who forged it from two even more primitive editing tools, ed and ex. Vi stood for "visual interface," which in 1976 was in quite the bleeding edge in computing, according to a Joy interview in Linux Magazine.
   
   "I was trying to make it usable over a 300-baud modem. That's also the reason you have all these funny commands. It just barely worked to use a screen editor over a modem, " Joy said "So the editor was optimized so that you could edit and feel productive when it was painting slower than you could think."
   
   In that interview, Joy contrasted the development environment of vi to that of EMACS, which, he said was written for systems with blazing fiber-channel links and monster PDP-10's.
   
   "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," Joy said, perhaps sounding a bit envious. "People don't know that vi was written for a world that doesn't exist anymore."
   
   Yet, while vi should have died out in the early '80s as network and processor speed increased, instead, it has flourished. The VI Pages lists close to 30 vi clones from elvis and VIM to such obscurities as WinVi and vigor.
   
   Tim O'Reilly, mastermind behind the O'Reilly & Associates publishing company noted on the company's Ask Tim column that his company sells twice as many vi books than EMACS ones. Plus, whenever O'Reilly sponsors a vi. vs. EMACS paintball game at some convention, invariably twice as many volunteers sign up to defend the honor of vi than EMACS.
   
   So what is the appeal? That's best described by the Cult of VI in which John Arundel writes, "Watching a vi guru doing some heavy editing on a file, as her fingers fly over the keys and textual transformations sweep across the screen, one could believe that one is in the presence of supernatural powers."
   
   Gil publishes a few examples of this wizardry on his Web site. "A key concept in vi is combining a certain action (delete, copy to buffer, capitalize, etc.) with a movement (go to line 25, go to end of document, go to next occurrence of 'foo,' go to 2nd occurrence of character 'x' in this line, etc.)."
   
   "Huh?" I email him.
   
   Gil sends back an example: "If, for example, a document contains the lines: 'a b c d e f g h' and the cursor is location on 'b,' then I can type 'd/f.' "
   
   The first "d" means delete, the "/" is a search function, so what this command will do is delete from b to f.
   
   "No special circumstances required to use this . . . Delete words, sentences. Go back to where I was before. 'Oh no, jump back again. Undo what I did, redo it,' " Gil writes.
   
   Gil stipulates you can do tricks like this one on EMACS, too. However, he says it requires memorization of unwieldy "funky Ctrl-X Ctrl-c Alt-F4 key combinations" to execute.
   
   Another trick Gil reveals is how VI allows users move around in files. "The stupid way is using arrow keys; there are many other, more advanced, ways to move around," Gil writes. Among the advanced forms of carriage vi offers is the option to jet to the last or last few cursor jumps, or to the next occurrence of a particular word, or to the next sentence or paragraph.
   
   Even the dual mode "feature" becomes transparent to users. About a year ago, A while back I interviewed Jon Lasser to write about his then-recently published book Think Unix, (the manuscript of which, he told me, was composed entirely in vi). The conversation eventually came around to vi, and I complained about the two modes.
   
   Lasser explained that he saw no difference between working in vi and in word processors like StarOffice or Microsoft Word. In Word, when you move your pointer out of the screen area, you can't type in text. You have, in effect, moved from insert mode to command mode. "It's the same thing," he explained.
   
   As O'Reilly wrote about vi: "Like a lot of things about UNIX, it only *seems* difficult."
   
   More is more with EMACS?
   
   When vi loyalist O'Reilly wrote in Ask Tim that he first shifted from EMACS to vi only after his customized EMACS profile was trashed, it was one of those subtle jabs vi users like to use against EMACS.
   
   EMACS stands in sharp contrast to vi's pristine limitation of commands, with its almost infinite customizability. Given human nature being what it is, however, such power in the hands of users may not always be a best thing.
   
   As the Emacs-Beginner-HOWTO puts it, EMACS can be a text editor, mail client, news reader, word processor, script editor, and integrated development environment for programming languages.
   
   The key to this is the multiple modes, each with a unique command set, that EMACS offers. Want to check email? Just flip over to the email mode. Want to writing a program in C++? Use the C++ mode. Need to author some Web pages? Flip into the html-helper mode.
   
   And on top of all this, you can also customize EMACS and even add new functions, usually through modifying the Lisp code.
   
   All of which many vi users see as terribly presumptuous for what is supposed to be a simple text editor, not to mention distracting for the user. The ongoing joke about EMACS is that it is an operating system with a text editor attached.
   
   "EMACS as such actually started out as a standards project," emails Guy Steele, one of the originators of EMACS, along with Richard Stallman, who later founded the Free Software Foundation.
   
   The way Steele recalls, Stallman maintained an early editor for PDP-10 called TECO, which stood for "Text Editor and COrrector."Although certain keystrokes would perform editing commands, Stallman created a user-programmable table "such that each keystroke performed a lookup in the table describing what to do for that keystroke," according to Steele. "One option was to execute a user-specified TECO macro."
   
   Using this macro functionality, users were programming custom sets of macros to be attached to various keystrokes, but this became problematic when programmers started collaborating on programs and found out they had few common keystrokes between them.
   
   "The user community had become fragmented with respect to the skills of text (and program) editing," Steele writes. So Steele, along with David Moon and Stallman, took on the project of integrating all the ideas into a unified command set.
   
   "I made up a matrix on paper and did a lot of running back and forth among the implementers and users of the various macro packages," Steele emails.
   
   "I remember this very well," recalls Dan Weinreb, who was one of the first alpha testers of EMACS. "Guy had a clipboard with a piece of paper showing all the key bindings, and he carefully and diplomatically collected input and comments from everyone to put together the unified, standard key bindings."
   
   After a few months, Steele, busy trying to finish his master's dissertation, handed the work over to Stallman. And the rest is history.
   
   That the flexibility was baked in from the start gives EMACS its edge, say hardcore users.
   
   "I think of EMACS as the Swiss Army Knife of editors," emails Debra Cameron, co-author of Learning GNU Emacs and president of Cameron Consulting. "It is a complete work environment, a microcosm. If you think of something you wish it did, you will probably find out (after looking around) that it already does it. If it doesn't, you can extend it and make it do what you wish it did."
   
   Can't we all just get along?
   
   So how does EMACS contrast to vi?
   
   "I have seen very adept vi users do some pretty neat tricks, but I still think vi is (just) an editor, even if for some it is a great editor," emails Cameron. "[It] always, always works the same way. In this sense, vi is like McDonald's; no matter where you go, it is exactly the same."
   
   "Do you want an editor that can be modified to your needs and quirks and which does many, many things or do you just want to be able to quickly edit files on any machine?" she asks. "For people who have to move around from one computer to another constantly, this consistency can be a real advantage."
   
   In other words, EMACS = flexibility, whereas vi = uniformity?
   
   Here's where things get murky.
   
   "EMACS is certainly more complex than vi, but I don't believe it's more powerful in any sort of useful way, because vi was designed to be part of a UNIX system and to interact with those tools," counters Jon Lasser.
   
   Mind you, for Lasser, "useful" means the way that vi allows you to read documents directly from a UNIX pipe from another process, "like you would in any other UNIX application," he explains. So, the arcane string of keystrokes " :r !ls" entered into vi (in command mode, remember) reads into the buffer the output from the "ls" program, or a listing of files from the current directory. And a pipe from any other UNIX program would work as well.
   
   As for editing a large number of files automatically in vi, Lasser says that's why we have "sed, awk, and all of the other UNIX text-processing tools.
   
   "Text processing is what UNIX was designed for, and vi was designed to be part of such a system," Lasser writes.
   
   Maybe the underlying issue between EMACS and vi isn't one of uniformity versus flexibility at all. After all, both editors offer flexibility, its just that with vi, it's through UNIX itself, whereas EMACS achieves it by building on top of the system.
   
   And, for that matter, the only point of flexibility anyway is to make the job go faster. If you wanted straightforward no-frills text processing, you could go with Pico, which offers just a blank screen and none of the newbie-confusing features of either vi or EMACS. What both of these editors offer are advanced ways of narrowing the gap between the speed of the fingers on the keyboard and the speed of the programmer's brain.
   
   In other words, could it be that these editors offer the same thing, but demand different ways of thinking from their users? Vi requires the patience to learn its quirky ways, though once you master them, you're free to take your act to any UNIX system. EMACS endows you with mad freedoms in customizing your setup as you see fit, though if you're not careful, you'll become prisoner to your own configuration.
   
   Sometime during the great hike of improving self-efficiency that all good programmers take, vi and EMACS users cross paths, each coming from a different direction. And when they meet, they usually throw stones at one another.
   
   But it's all good.
   
   "I don't think there is a strong difference in functionality. Both editors do a fine job and it just comes down to what people learn first," Gil writes. "Since most people know EMACS, they will teach others EMACS. Hence, most people use EMACS, etc."
   
   And so the feud will continue ...
   
   (Note: Capitalization of EMACS, UNIX and vi may have been changed in quotes to their original forms, except in direct titles of books and Web pages).