Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!spool.mu.edu!cs.umn.edu!uc!norge.unet.umn.edu!fin From: fin@norge.unet.umn.edu (Craig A. Finseth) Newsgroups: comp.editors Subject: Re: Xedit is better than vi and emacs Message-ID: <3817@uc.msc.umn.edu> Date: 3 Apr 91 23:13:36 GMT Article-I.D.: uc.3817 References: <2197@pdxgate.UUCP> Sender: news@uc.msc.umn.edu Organization: Univ Netw Serv, Univ of Minn Lines: 55 In article <2197@pdxgate.UUCP> jonr@eecs.cs.pdx.edu (Jon Edmund Richards) writes: > My boss made the statement last week that, in many ways, > Xedit is better than vi and emacs. We argued about this > for awhile with the end result that by Friday I have to > present a paper either supporting my belief that Xedit > has outlived its usefulness or a description of how Xedit > surpasses my favorite Unix editors. ... This is an argument that is impossible to win. On the other hand, there is no particular reason why it should be necessary to win it. There are several surface reasons why it is impossible to win. They all boil down to the same thing: one's choice of editor is a religious (used in the technical sense) issue. As such, it is not one that can be discsussed rationally. To each person, it is so obvious that their favorite editor is so much better than all the rest, they cannot understand why everyone else doesn't immediately convert. This "obviousness" comes from the editing models offered by each editor: the user's favorite editor has a model that matches that user's expectations. As long as we are discussing text editors, however, this is all a non-issue. All system editors can read and write the same files. Thus, if you want to use editor A on a file and your boss wants to use editor B, who cares? The resulting file is identical. (This argument gets more complex when you are discussing word processors with their *@%#! file formats, but that is not an issue here.) The way to win is *not* to say "editor A is better than editor B." Rather, it is to say "editor A is better than editor B for user X, and it is the other way around for user Y." Now, someone may come back and say "it is too much work to support both A and B." The counter argument must be made on those grounds: it takes X amount of work to install a new editor, but using it will improve user Y's efficincy by Z%, so the breakeven time is ." For example in my case, installing Gnu-Emacs took about 1/2 day. My performance improvement (vis-a-vis vi) is about 900% (i.e., I can work at least ten times more efficiently). I come out ahead in about a day. And if someone says, "it takes too much disk space, CPU time, etc.," then they really are lost in the 1960s and you need to ask them why they are using computers and not pencil and paper. This is, after all, 1991 and I run an Emacs-type editor on my RAM-disk-based laptop. What could be more disk-limited than that? Craig A. Finseth fin@unet.umn.edu [CAF13] University Networking Services +1 612 624 3375 desk University of Minnesota +1 612 625 0006 problems 130 Lind Hall, 207 Church St SE +1 612 626 1002 FAX Minneapolis MN 55455-0134, U.S.A.