Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!cbatt!ihnp4!houxm!genesis!hotlg!nz From: nz@hotlg.UUCP Newsgroups: comp.text Subject: Re: edt or vi? Message-ID: <10@hotlg.ATT> Date: Thu, 8-Jan-87 15:00:52 EST Article-I.D.: hotlg.10 Posted: Thu Jan 8 15:00:52 1987 Date-Received: Fri, 9-Jan-87 21:12:58 EST References: <241@tellab5.UUCP> <397@jimi.cs.unlv.edu> Reply-To: nz@hotlg.UUCP (Neal Ziring) Organization: AT&T-BL Dept. 54315 Lines: 287 Keywords: EDT sucks In article <397@jimi.cs.unlv.edu> robert@jimi.cs.unlv.edu (Robert Cray) writes: > In article <241@tellab5.UUCP> etan@tellab3.UUCP (Nate Stelton) writes: > > > >I am a UNIX/vi user who was recently told about EDT (VMS), and I would > >like to solicit some comments. What I'm wondering is: > > > >1. Is EDT a superior text editor to vi? > > No. VI has many things EDT does not, regular expressions, > the g & v commands, conditional replacement, the undo command, > and lots more. EDT does not really do anything. That's not strictly true. I have seen several editors that do less than EDT (mostly on IBM systems). Consider that the predecessor to EDT, K52 or KED, was written to run on non-separate-I&D PDP-11s. Rob Cray is correct in telling Nate that VI has many things that EDT does not have. EDT also has things that VI does not have, although not as many. > If you want to use an editor under VMS, you should you EDIT/TPU > This editor has multiple windows, the ability to execute commands > on a buffer, and can be extended. It does not have regular exp. > built in, but has the functions needed to build it yourself. I agree that EDIT/TPU is superior to straight EDT. EDIT/TPU does have the difficulty that it requires a higher degree of intelligence on the part of the terminal to work at all. TPU is a neat language, too. However, the vanilla EDIT/TPU still behaves a lot like EDT on the surface. > Better still would be to use GNU emacs, it is free, ... Again, I agree. GNU Emacs version 17 runs very well on VMS, and provides features that EDIT/TPU and EVE do not even pretend to approach. It is not very robust, for a variety of reasons, and it might be advisable to wait for version 18 (due in a few weeks, read recent articles in comp.emacs). > > > >2. Is there a version of EDT that can run under UNIX 4.2(or3) BSD? > > > There is an emulator of EDT that runs under GNU Emacs. This > comes with the latest dist. I think Anybody used to the real EDT may be frustrated by GNU's insistence on using the entire screen for editting, rather than only the top 2/3 :-). Also, some of the more VMS-specific parts of EDT are not included in the emulation mode. > >3. Is VMS a better environment for electronic publishing than UNIX? (I.e., > >fuller support, more powerful tools). Not a chance! Disregarding text editors, you have more options and much more flexibility for printing, typesetting, etc.. on a good UNIX system than you do on a VMS system. Further, the wealth of other tools available under UNIX can come in handy at the darnedest time. I once had to do a rather complicated match-replace-accumulate-and-dump sort of operation on a document (a User's Guide, about 40 p.) I was writing. I used a pipeline including tr(1), sed(1), and awk(1). You won't find tools like that, or the flexibility in hooking them together, anywhere in VMS-land. > I have found that everything VMS has, UNIX has, plus a lot more. > It is much easier to do development under unix. True. VMS has some neat stuff, and there are things that are easier to do under VMS than under UNIX, but editing isn't one of them. > VMS has Digital standard runoff,TeX & WPS, Unix has troff (like > DSR except much better) and TeX. I have yet to talk to anyone > that didn't hate WPS, so that leaves TeX, which you have on UNIX. > > I think TeX is the best of all of them, this also is free and runs > on lots (UNIX, VMS, TOPS-20, IBM-PC, Mac, Amiga) of machines. TeX is demonstratably the best of them all, as well as the most widely distributed. For example, you can write a Towers of Hanoi solver in Troff, or in TeX, but not in DSR. WPS I don't know anything about, but I have heard that it is not so hot. > The only reason to use EDT on unix is if you don't have time to > learn GNU or vi. Right now I use eve under vms and find it > acceptable (You just about have to customize it, the way it > comes is quite obnoxious, so don't be discouraged) EVE is pretty neat. It does have windows, and multiple buffers, but the design is poorly thought out in some regards. For instance, as I understand EVE, you can pull many files in for editing, but you can never dispose of them. As usual for VMS utilities, it is also keypad-based. Keypads are nice if your terminal has one, but if it doesn't... > --robert > Now, for your reading pleasure, I will attack ANOTHER article on this same topic! In article <172@pembina.alberta> bjorn@alberta (Bjorn R. Bjornsson) writes: > In article <397@jimi.cs.unlv.edu>, robert@jimi.cs.unlv (Robert Cray) writes: > > In article <241@tellab5.UUCP> etan@tellab3.UUCP (Nate Stelton) writes: > > >I am a UNIX/vi user who was recently told about EDT (VMS), and I would > > >like to solicit some comments. What I'm wondering is: > > > > > >1. Is EDT a superior text editor to vi? > > Yes, for 95% of editing tasks. Use vi/ex, sed, awk or Gnumacs > for heavy duty manipulations. That is a pretty bald statement (so was Robert Cray's, to be honest). It would be interesting to see ``Gibson Mix'' of editting tasks, and compare (what metric to use?) EDT to vi on such set of task. One of the prime tenets of EDT seems to be: Don't Let that User Put His *&!%$&^@$ Hands on the Home Row! Anybody who is trained to type quickly finds: (a) that keypads are distasteful or (b) typing skills sure deteriorate quickly. I was always told in typing class that the key to fast and reliable typing OF ANY KIND was to keep your hands on the home row and your eyes off your hands. In EDT (and TPU, and EVE) this goal is impossible. > > No. VI has many things EDT does not, regular expressions, > > the g & v commands, conditional replacement, the undo command, > > and lots more. EDT does not really do anything. > > True vi has many things that edt does not. Regular expressions are > sorely missed, etc.. From a strictly formal standpoint, regular expressions make all the difference, because full regular expressions have all the power of a finite automaton, and fixed strings do not. One point that you are missing, and it is a VERY IMPORTANT ONE, is that EDT is built to be a closed system, vi is built to allow you to use all the power of the operating system. There is no way (at least I never heard of one) that you can ask EDT to send a portion of your file through a filter, much less a set of filters. Now, with EDIT/TPU, you can write filters in TPU, but it is still nice to be able to use filters that are already available. Needless to say, GNU allows you to do this filtering business, too. > Much as I hate to paraphrase John Kenneth Galbraith, I still think > he has the definitive comment on the matter (no the original was > not about text editors): > > Where text editors are concerned there are few standards. > No one can say what is good and what is bad, although you > can be sure that everyone will. Sure enough. I have learned a lot from listening to the opinions of older and wiser men (and women). If my opinions, and those of Robert and Bjorn will help Nate learn more about editors and computers, then maybe the argument wasn't in vain after all. > I know you won't believe me butedt and > likes it> I knew some folks like that. They were all ``infrequent users'', not sitting-at-a-terminal-half-the-day-every-day types. If there are any EDT fans out there in netland, remember how tried your arm got from switching from keypad to keyboard after a 6 hour edit session? > Me, I saw edt before I > saw vi and you know by now which one I prefer. It's fairly easy > to modify just about any of the microEmacs editors that have been > posted to the net to emulate edt keypad mode + use regular expressions. Yes, but that doesn't give you all of EDT. I get annoyed quickly with skin-deep emulators, and I know many experienced programmers who agree. > Oh and by the way, on of the premier features in edt is reverse video > on "select ranges" (regions to you Emacs hackers). This has not > been duplicated (for obvious reasons) in any Emacs package written > to emulate edt. Really? I have heard of that feature, but never used it. I think I would go mad if I saw an editor do that more than twice! Just think of the number of characters it has to send to mark up half the screen in reverse video! Just for selecting a range that you are about to delete anyhow. CCA Emacs had a neat feature where you could set the other end of the select range (region) to reverse (just one char). GNU doesn't do that, unfortunately. One problem with EDT, of course, is that you cannot have multiple select ranges. You have one mark, and that's it. Vi has 26 (one for each letter of alphabet), and most Emacses have 26 or more. > Bjorn R. Bjornsson > alberta!bjorn Just to get this discussion onto solid ground, I have made up a quick list of features and a comparison of how they are implemented, and their level of availability, in 3 editors: VMS EDT, UNIX (SystemV) vi, and GNU Emacs. I would like to include EVE, but I don't know enough about it. Please would some VMS hacker out there will post a column for EVE? Feature EDT Vi GNU ---------------------------------------------------------------------------- Searching | Fixed | Partial Regular | Full Regular | Patterns | Strings | Expressions | Expressions | | | | | Replacement | Fixed Strings | Regular Exprsns | Regular Exprsns | | No Control | y/n/q control | y/n/q/e control | | | | | Edit Buffers | Exactly One | One, with alt. | Up to 1023 (?) | | | | | Edit Windows | One | One | Many, user | | | | configurable | | | | | Key Control | Little to none | Keys can be re- | Fully customizable| | (TPU fully conf.) | defined, runtime | | | | | | Term Indep. | No (TPU is, tho) | Yes | Yes | | | | | Line Edit Mode| Yes | Yes | Mostly No | | | | | Tab Control | Yes | Partial | Yes | | | | | Spawn CLI | Yes? | Yes | Yes | | | | | Perform CLI | No | Yes | Yes | Command on | | | | Edit text | | | | | | | | Language Sen- | No (EVE has some) | Mostly No | Yes | sitive Modes | | | | | | | | Macros | Keyboard Macros | Sequential Cmd. | Keyboard Macros | | (EVE has TPU?) | Macros | Emacs-Lisp | | | | | Undo | No | Yes, 1 step | Yes, 32 steps | | | | | Rectangle Ops | No | No, but can use | Yes | | | filters and CLI | | | | | | Auto-Fill | No | Yes | Yes | | | | | Text Justify | No | No, but can use | Yes, some, and | | | filters and CLI | can use filters | | | | | Directory Edit| No | No | Yes | | | | | Re-indent C | No | No | Yes, C & Lisp | or other Code | (EVE has F77?) | | | | | | | Send Mail or | No | No | Yes | read News | | | | | | | | On-Line Help | Yes, some | No | Yes, complete | | | | | Case Sensitive| No | Yes | Either | | | | | Spell Check | No | No, but can use | Yes | | | filters | | | | | | Arbitrary Mvt.| No | Yes | No | Regions for | | | | Commands | | | | | | | | Can Emulate | No | No | Yes | Turing Machine| | | | | | | | File-Name | No | No | Yes | Completion | | | | | | | | Show Paren | No | Yes, on | Yes | Matches | | screen only | | | | | | Proprietary | Yes | Yes | No | | | | | Implementation| BLISS (?) | C | C and Elisp | Language | (TPU for EVE?) | | | | | | | Places to | 1 | 26 | 26 | Squirrel Away | | | | Text | | | | | | | | Kills Kept | 1 | 10 | 30 or more | | | | | Max Line Len | 32768? | 512 | available memory | | | | | Special Fcn. | No | No | Yes | Libraries | (TPU can do this) | | | | | | | I could go on, but I think you get the idea. Any additions from editor fans out there? Any mistakes (probably)? [This article entered with GNU Emacs version 17.64] -- ...nz (Neal Ziring @ ATT-BL Holmdel, x2354, 3H-437) "You can fit an infinite number of wires into this junction box, but we usually don't go that far in practice." London Electric Co. Worker, 1880s