Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!mayoff From: mayoff@cs.utexas.edu (Robert Mayoff) Newsgroups: comp.editors Subject: Re: vi Alternative Required (long posting) Message-ID: <1010@grit.cs.utexas.edu> Date: 6 Dec 90 23:43:21 GMT References: <1005@langtry.cs.utexas.edu> Organization: Dept of Computer Sciences, UTexas, Austin Lines: 265 In article joshi@cs.uiuc.edu (Anil Joshi) writes: > >mayoff@cs.utexas.edu (Robert Mayoff) writes: > >>In article joshi@cs.uiuc.edu (Anil Joshi) writes: >>>The point of the matter is that vi sucks in sveral ways, where as >>>ISPF is a truly wonderful editor. >>Whoah. A bit of an opinion, don't you think? >What is wrong in expressing an opinion? Absolutely nothing is wrong with expressing an opinion. However, presenting your opinion as if it were a proven fact in a situation where there's going to be debate can only raise some hackles. >Have you used ISPF on MVS? No. >>vi is my favorite editor, but it is not for everyone. I love vi because of the >>speed it offers. vi, in general, offers the best response time I've seen, and > ^^^^^^^^^^^^^^^ >Compared to emacs (are there any choices in the UNIX world for editors >other than vi and emacs? I am not asking for developing a new one. But >does there exist an editor other than emacs/vi?) Well, there's jove (John's Own Version of Emacs), mg (a stripped-down version of GNU Emacs), and epcoh (GNU Emacs hacked for better X support), to name three :-). I can't really think of any major UNIX editors except for vi and emacs, though. Certainly not ISPF - I've never seen a version for UNIX. >>eliminates the problem of taking my hands off the home row. I freely admit >Then why don't the real typist/secretary types like this editor? What >does UNIX land has to offer to these people? Some editor like XEDIT >(under Xwindows) which requires some fancy/costly hardware and still >makes one go through gazillion screens to repeat a search? First, let me humbly suggest that if you are refering the to sample program "xedit" distributed with the X distribution, refer to it in lower case. I think of XEDIT as an IBM mainframe editor, and of xedit as a (poor, underpowered) UNIX editor that wishs it were running on a Mac. Re: Why don't the real typist/secretary types etc.? Well, I suppose it's mainly because they don't want to think about "modes." However, I suggested vi or emacs for "power" users - by which I meant people who program, or at least know how to diagnose simple problems without calling for help. Yes, there are secretaries who can figure out what the problem is when their computer hangs, but most that I've worked with cannot. That's not their job, and it's not in their training (usually), so it doesn't bother me. For them, I suggest PE2 (or XEDIT). Actually, I'd suggest a Mac. I know I'm going to get flamed, but I actually believe that for most people, a Mac is the way to go. Most people want to learn as little as possible about computers, and I don't consider that a crime, or even lazy, the way some people do. It's very easy to learn to do stuff on a Mac. I know, there's also a lot less that can be done, but most people I know that have to use computers (but don't necessarily like it) prefer Macs, even after having used alternatives. >> [vi/ex stuff deleted] > >The problem I find with these editors is that the manuals are hard to >get. One has to read the research papers that were written by the >original authors etc. Why can't there be a reasonable and comprehensive >manual with lots of examples? You are perfectly correct; manuals are often hard to come by. However, the SunOS documentation comes with manuals: The "SunOS Documentation Tools" binder has a section entitled "Editing Text Files," which has sections on vi, ex, ed, sed, head, tail, cat, more, view, [ef]grep, look, rev, wc, awk, diff[3], comm, join, and uniq. In addition, many bookstores carry at least a few books on UNIX, and there are a host of books about vi/ex that you can buy that detail the two and give complete command lists. >Talking about ex, one can use abbreviations to do a lot of good stuff but the >ex macros (I am calling the abbreviations macros) are also key stroke >dependent (like having to hit ctrl-v before inserting other control >chars. into the macro.). Is there some way of getting parameters to the >macros? No. >Another problem which I have not solved yet is that while I am editing a >file and want to change my function keys, can I run some other .exrc >like file from inside the editor? I can do it the long way by typing in >all the map commands but I think there must be a short cut to this. >There must be, if these editors are as powerful as you claim them to >be. It is definitely not exotic. The "so" ex command reads a file, treating it as input to ex. This command is implicitly performed on startup on your .exrc file unless your EXINIT environment variable is set. However, typing ":so filename" in vi will source the commands in the file named as ex commands. >I do not have anything against reg.exps. The real problem is the >insistence that what ever one has to do should be done only through >reg.exps. There are other ways of doing this stuff. This like the >history command in C-Shell. If you want to change even a teeny-weeny >little character somewhere in the middle of the previous command, you >start with a reg.exp. substitution. Don't you think it would much >simpler just present the command in the input buffer and let the user >change the portion he/she wants through cursor keys, spaces, delchar key >etc. Yes. It would be. In fact, modern shells (ksh, tcsh, and bash) DO offer visual command-line editing. However, there is something in csh called "quick substitution" that doesn't require the use of a regexp. man 1 csh and look for it if you care. This isn't really the place for a discussion of shells; the fact that the shells support (limited) regexps is incidental to this topic. > >>probably). Another feature about vi is that the user can pipe parts of a file >>through a filter. > >I want to do this. I have not yet figured out how I can pass a part of >the file through a filter. I know how to do this for the entire file >though. Here's how you might do it: < Go to first line of text to be filtered > ma < Go to last line to be filtered > !'aCOMMAND Substitute whatever command you want for COMMAND. There are simpler ways, though. For example, you can filter a paragraph through the fmt command by going to the first line of the paragraph and typing "!}fmt". >>The ISPF editor is a very old editor, but still useful. However, given the > >May be you used the older version. Maybe. I don't know. What I meant was that its origin is lost in the cloudy history of computation, and it still bears the marks of that origin. Same with vi, ex, and emacs. However, vi was born about ten years after ISPF, I believe. >IBM keeps on making improvements in a >systematic way and documents everything. There is strict QC and you can >be more or less assured about its reliability. What do vi and emacs >have to offer in this area? Am I wrong in assuming that >they have been basically developed by some grad. students? Originally, yes, it was developed by some grad students. I don't know entirely what path its evolution has taken since then. However, I *do* know that some improvements have been made in various versions - bug fixes, SIGWINCH handling, and a showmode option, for example. >I also have a >feeling that some of the computer science hacks are too caught up in >their own little hacking tricks like named pipes or whatever and >sneer at the users. Do you think that they would care too much about the >poor typist/sceretary who has to use these tools? Now, on the otherhand, >if they were to make money, they would put everything they have got into >it. You are correct. There is a real problem, which I bear also, of knowledgeable users (such as you and me, I assume) considering users not so dedicated to mastering these arcane arts to be "second-class citizens." I know that these guys who come into the lab and power cycle a Sparcstation because they don't know about screenblankers are not the scum of the earth; nevertheless I and others treat them with scorn. I'm sure that if I walked into a book-discussion group that one of these users was a member of, and said "You know, I think that the main character of Billy Budd is an analogy for all sailors," they'd treat me the same way. It just so happens that I'll never do that; that's no excuse for my sneering at them when they fuck up in an unfamiliar situation. >The popularity of emacs arises from it being a free-bee package than >anything else. If one was paying some good $s for it, one would demand >more. IBM sells ISPF for real $s and they spend enough money on >research and continually improve their products. This is true with any >company (be it Apple or DEC etc.). Well, now, it's not a good idea comparing emacs and ISPF on the basis of money. Remember that GNU Emacs (the most popular and most powerful version) was created by Richard M. Stallman. RMS is the founder of the Free Software Foundation, and believes that all software should be free; he (along with many others) is working on a completely free version of UNIX (Gnu's Not Unix - a recursive acronym). Other versions of emacs (for example, UniPress Emacs) do cost money, and they do have companies backing them. As for "continually improving," check out the voluminous amount of Elisp code available for emacs to do everything from reading mail to editing fonts! Anytime some new language appears on the scene, you can expect someone to write a GNU Emacs mode specifically for it. It is my speculation that as much effort goes into maintaining and enhancing GNU Emacs as goes into maintaining and enhancing ISPF (at least, the editor portion of ISPF). >Actually the division is along many lines. It actually stems from >the debate of MVS vs VM/CMS. I think that ISPF with VM/CMS is bad and >same is true with XEDIT with MVS. I wouldn't know; I've never used MVS. >I don't know why you got the >impression that I am rooting for any one of these editors. I think many others on the net understand exactly why - your first statement, quoted below: >>>The point of the matter is that vi sucks in sveral ways, where as >>>ISPF is a truly wonderful editor. Hmm. Seems pretty broad and sweeping. You reiterated that ISPF was better than all other editors that you mentioned in your posting. I'm not saying that what you wrote is exactly how you feel; I'm merely pointing out where I got my impression. >I am merely >saying that "Take the good things out of ISPF, out XEDIT, out of the >other program editors and give them as standard features". Obviously one >cannot do this because some of the features can be contradictory. So, >what is the yard stick to be used? Keep the features that are used by >90% of the people for 90% of the time. Obviously, you need an >enlightened set of users for this. So educate the users, write good >manuals, have sensible defaults, be user friendly and be adaptive to >user needs and go on making improvements. Obviously all these things >would cost money. So "there is no free editor". Okay, you're right about what needs to be done (except that you don't need to take out the remaining 10% of the features). We *do* need good manuals, and we *do* need the most-used features, and we *do* need educated users, and we *do* need user-friendliness, and we *do* need to be adaptive and keep making improvements. However, while it is true that money can help accomplish all these goals, it is not necessary. I present GNU Emacs as my evidence; it has a good manual, is well-supported and flexible with full and extensive on-line help, and is completely free - with source! I don't think you get the source to ISPF even if you buy it (though I could be wrong). >I don't remember the exact command but you can easily disable these. >These line numbers have several nice uses though. For one, the labels >are displayed on these line numbers. Secondly, blocks are dellimited by >putting in line commands in this area. All your labels are visible. >I can think several nice things that are visible in the line area which >is not used in vi at all. I *do* like line numbers at times; however, I want to be able to turn them off. In the MVS version, perhaps it is possible; however, I could not figure out how in the VM/CMS version after searching the manual and asking a couple of ISPF experts. >You can scroll horizontally to your hearts content and you don't have to >use some 200 hundred fingers to do this (or write a mcro). I don't understand what the "200 hundred fingers" reference means; however, the point is that to read each line you have to scroll right to see the missing eight columns, and then scroll back left to read the beginning of the next line. Now, if you can deactivate line numbers, then you don't have this problem. >There is a problem. Keys cannot be redefined. But it is not such a big >deal. Hmm. I guess our opinions differ on this - I want to be able to redefine keys. >>3270s. I have used a version for PCs, but it simply simulated a 3270-style >>terminal. Hence, no scrolling. Don't get me wrong - I perfectly understand >>the logic behind the 3720 terminal concept (screen-at-a-time). I agree that it >>has modern uses, and is an efficient solution to some problems. However, as a >>terminal running an interactive text editor, it *sucks*. In my humble opinion. >>ISPF and XEDIT were built around that fact; I can only regret that if >>character-at-a-time terminals had existed when they were written, the >>state-of-the-art in interactive editors might be that much further along. >You are totally wrong in this. Character-at-a-time terminals use old >technology. They are the ones who do not have any sizeable buffer. If >the OS (or some OS process) doesn't take it off its hands, the >characters are lost. Every time you press a key, the entire interrupt >sequence is invoked. Ever wonder why UNIX editors are so slow? You are right in that character-at-a-time is old, older than screen-at-a-time. However, it is modern in that modern processors can accomodate it easily. And while character-at-a-time can simulate screen-at-a-time perfectly in software, screen-at-a-time can only approximate character-at-a-time. I think that screen-at-a-time is a good thing; for CICS it's perfect. However, when I cursor down off the bottom edge of the screen, I want the screen to shift accomodate (i.e., scrolling). You can't do that with screen-at-a-time (at least, not with a 3270). >>So, in summary, PE2 for users, vi (or emacs) for "power users". And if you're >>screwed - er, I'm mean stuck with a 3270-style terminal, I'd go with XEDIT - > ^^^^^^^ >Yes I am screwed. I am stuck with vi and/or emacs and dumb esprit >terminal which shows only 24 lines. Yes, you are screwed. Try to find a workstation, or at least an X terminal, if you can. :-) -- /_ rob /_ Fun things to do with UNIX (#72 in a series): / cat /dev/zero > /dev/null Brought to you by Super Global Mega Corp .com