larry@bradley.bradley.edu (Larry D. Stratton) (01/31/91)
Good God! I do know how to survive using vi and emacs. I've been using them for months. The point is that a new programmer has an exaggerated learning curve with these products as opposed to an editor with function keys defined and use of the full range of keys on the keyboard. The objective, my dear sir, is not the mastery of an editor but rather the productivity of the staff. Yours is a typical answer of a CS rather than a manager. Get real. -- ************************************************************** L. D. STRATTON "If you had listened hard enough you larry@bradley.edu might have heard what I meant to say. BRADLEY UNIVERSITY Nothing." - - - - McKuen
jfy@orion.cis.ksu.edu (Joseph F. Young) (01/31/91)
larry@bradley.bradley.edu (Larry D. Stratton) writes: >Good God! I do know how to survive using vi and emacs. I've been using >them for months. The point is that a new programmer has an exaggerated >learning curve with these products as opposed to an editor with function >keys defined and use of the full range of keys on the keyboard. > Do not trouble us with your problems with these editors; I for one, do not like function key based editors (Wordperfect stands out as one of the worst cases..."Was it Alt-shift F1 or Ctrl-shift F3 to do this command?"). Not everyone can afford to have nice terminals or workstations which can support some function key driven editor. Learning any editor takes some sort of a learning curve, depending upon what one has been exposed to. Emacs and vi have the virtue of being consistent to a high degree over a broad range of platforms and operating systems; I have yet to see some function key based editor achieve that, due to the fact that there is little standardization of keyboards beyond the basic QWERTY setup. >The objective, my dear sir, is not the mastery of an editor but rather the >productivity of the staff. Yours is a typical answer of a CS rather than a >manager. Get real. Get real yourself. Do not delude yourself with the idea that you know what the "ideal" editor is. A person's ease in using an editor is highly dependent upon what one is used to and how one likes to do things. This is more a matter for "alt.religion.computers" than "comp.editors". -- Joseph Young, KSU Department of Computing and Information Sciences Manhattan, Kansas 66506 FAX: (913) 532-7353 Phone: (913) 532-6350 Inet: jfy@cis.ksu.edu UUCP: rutgers!ksuvax1!jfy -- "MS-DOS...just say no."
dylan@ibmpcug.co.uk (Matthew Farwell) (02/01/91)
In article <1991Jan30.224717.6150@bradley.bradley.edu> larry@bradley.bradley.edu (Larry D. Stratton) writes: >Good God! I do know how to survive using vi and emacs. I've been using >them for months. The point is that a new programmer has an exaggerated >learning curve with these products as opposed to an editor with function >keys defined and use of the full range of keys on the keyboard. > >The objective, my dear sir, is not the mastery of an editor but rather the >productivity of the staff. Yours is a typical answer of a CS rather than a >manager. Get real. But if the staff were to master a editor then their productivity would increase.... Let me cite an example. In my younger days, I had a text file which was the basis of a program I was writing. (It was actually an interactive version of the purity test, which then added up the yes answers and gave the results to you. It actually also mailed the individual answers to me, but thats by the by). Anyway the line were something like 1) Have you ever done this and that in a moving land vehicle of over 800 tonnes unladen weight, blah blah blah. I spent about three days going through this file changing each question so that the input looked like 1) blah blah blah *** 2) blah blah blah2 *** etc. Now if I'd known how to use the editor properly at that time, I could have written a macro or two to cope%, ie :map q /^[0-9][0-9]*)^MO***^[jv :map v q :se nowrapscan Which would complete the job in significantly less time than three days. Another example: The other day I had a 400 line perl script in which I wanted (for various reasons) to change all instances of if (<test>) { die("<message>\n"); } to die "<message>\n" if (<test>); This took me 20 seconds or so (one vi macro), instead of 20 minutes which it would have taken if I'd done it manually. If you wanted to loop thru a lot of lot of files changing all instances of #include "foo.h" to #include "whee.h", again thats two simple macros. If you want productivity to go up, then you should teach your programmers to use an editor properly, not tell them to use function keys. Dylan. -- % Admittedly, all of these particular example could be done using sed/awk/perl, but thats not the point of this article. -- Matthew J Farwell | Email: dylan@ibmpcug.co.uk The IBM PC User Group, PO Box 360,| ...!uunet!ukc!ibmpcug!dylan Harrow HA1 4LQ England | CONNECT - Usenet Access in the UK!! Phone: +44 81-863-1191 | Sun? Don't they make coffee machines?
gardner@shl.com (Gardner Buchanan) (02/02/91)
>>[...] with function >>keys defined and use of the full range of keys on the keyboard. > [...] (Wordperfect stands out as one of the worst >cases..."Was it Alt-shift F1 or Ctrl-shift F3 to do this command?"). It was Ctrl-Alt-Meta-Underline-TeddyBear-Squiggle-CokeBottle. It's a shame that all terminals to not have a large standard set of extra "function" keys, but they don't. It is simply a fact of life that terminal independent editors - which IMHO every editor of consequence is - will have to overload the regular keys. Personally I like the way vi does this much better than the way emacs does. -- Gardner Buchanan gardner@shl.com Systemhouse, Ottawa (613) 236-6604 x375
gast@lanai.cs.ucla.edu (David Gast) (03/03/91)
In article <1991Jan30.224717.6150@bradley.bradley.edu> larry@bradley.bradley.edu (Larry D. Stratton) writes: >Good God! I do know how to survive using vi and emacs. I've been using >them for months. The point is that a new programmer has an exaggerated >learning curve with these products as opposed to an editor with function >keys defined and use of the full range of keys on the keyboard. I don't agree. vi, for example, does use the full range of keys. I have several function keys defined, but not to short character sequences. Even if vi or emacs had 12 or 16 function keys defined, would that really help if you did not have a template. And how is "function 6" more mnemonic for next line than "control-N" or j (if you know the ascii code). How can a programmer not know the Ascii code? >The objective, my dear sir, is not the mastery of an editor but rather the >productivity of the staff. Yours is a typical answer of a CS rather than a >manager. Get real. I suggest that you get real. Even if your argument that the staff can learn an editor other than vi or emacs faster for initial use is true, I doubt that these other editors are fasters after one becomes proficient. Further, I presume that you are not primarily interested in employees who work for one week, but those who work for years. As such, vi/emacs will provide greater productivity. Finally, if you hired me (not that I could be hired), you would find that my productivity is much higher with vi/emacs than some other brain dead editor. Perhaps yours is the answer of someone who only looks two weeks ahead. David
joshi@m.cs.uiuc.edu (Anil Joshi) (03/05/91)
gast@lanai.cs.ucla.edu (David Gast) writes: >In article <1991Jan30.224717.6150@bradley.bradley.edu> larry@bradley.bradley.edu (Larry D. Stratton) writes: >>Good God! I do know how to survive using vi and emacs. I've been using >>them for months. The point is that a new programmer has an exaggerated >>learning curve with these products as opposed to an editor with function >>keys defined and use of the full range of keys on the keyboard. I share his feelings completely. Exaggerated learning curve is not the only problem with these editors. They presume that user computing is a myth. Try teaching reg.exprs. to an end user. >I don't agree. vi, for example, does use the full range of keys. I have >several function keys defined, but not to short character sequences. >Even if vi or emacs had 12 or 16 function keys defined, would that really >help if you did not have a template. And how is "function 6" more mnemonic >for next line than "control-N" or j (if you know the ascii code). How can >a programmer not know the Ascii code? What about map! ^X^C^V&^%? Is that mnemonic for you? You must be kidding. >I suggest that you get real. Even if your argument that the staff can learn >an editor other than vi or emacs faster for initial use is true, I doubt >that these other editors are fasters after one becomes proficient. Further, Are you talking about speed of editors here or speed of usage? For one, emacs is the slowest thing I have seen in my seven years of experience. vi by no means is an editor by design. Ergonomics is a greek word for the designers/supporters/ users of vi. >I presume that you are not primarily interested in employees who work for >one week, but those who work for years. As such, vi/emacs will provide >greater productivity. Finally, if you hired me (not that I could be hired), I think you are totally wrong here. I am curious as to how much time you have spent in the industry. And please look around you and count the number of users who would like vi/emacs. What choice a UNIX user has got? vi or emacs. Both of them suck (IN MOST OF THE CASUAL USERS' opnion). The very fact that some time back we saw a posting about a lynch party going to the systems programmer asking him to change vi to look like ISPF or Word Perfect is a dead give away. >you would find that my productivity is much higher with vi/emacs than some >other brain dead editor. Get real. Go get a job in the real world. >Perhaps yours is the answer of someone who only looks two weeks ahead. Yours is the answer who has a completely cloistered outlook on life. >David Anil -- "Whatever we wish ourselves to be, we have the power to make ourselves. If what we are now has been the result of our own past actions,then it certainly follows that whatever we wish to be in the future, can be produced by our own present actions." - Vivekananda, Late Nineteenth Century Indian Philosopher
tchrist@convex.COM (Tom Christiansen) (03/05/91)
From the keyboard of joshi@m.cs.uiuc.edu (Anil Joshi): :>In article <1991Jan30.224717.6150@bradley.bradley.edu> larry@bradley.bradley.edu (Larry D. Stratton) writes: I counted to 5 and still wasn't content, so here goes. Do we really need a religious war here? :gast@lanai.cs.ucla.edu (David Gast) writes: : : :>>Good God! I do know how to survive using vi and emacs. I've been using :>>them for months. The point is that a new programmer has an exaggerated :>>learning curve with these products as opposed to an editor with function :>>keys defined and use of the full range of keys on the keyboard. : :I share his feelings completely. Exaggerated learning curve is not the only :problem with these editors. They presume that user computing is a myth. Try :teaching reg.exprs. to an end user. Say what? You don't HAVE to learn them. Anyone who wants to learn will learn them easily. Trying to force feed them on someone who doesn't understand why he would want one might have a bad reaction, but this is such basic stuff that I don't believe anyone who wants to learn them can't. If so, we have a broom waiting for him. :What about : :map! ^X^C^V&^%? : :Is that mnemonic for you? You must be kidding. It's my keystroke sequence. Once the keystrokes make sense, the bindings do to. It's not a program language, but big deal. It does go a long way. :>I suggest that you get real. Even if your argument that the staff can learn :>an editor other than vi or emacs faster for initial use is true, I doubt :>that these other editors are fasters after one becomes proficient. Further, :Are you talking about speed of editors here or speed of usage? For one, :emacs is the slowest thing I have seen in my seven years of experience. Which emacs? There is no One Emacs -- microemacs can be as small as vi. It doesn't have to be slow. Gnu's is slow on small machines, but that's only a subset of emaxen in a subset of environments. And I haven't heard anyone claim vi was too slow to use since we got the 750's load down below 25. :vi by no means is an editor by design. Ergonomics is a greek word for the :designers/supporters/ users of vi. And what is it then, a mail reader? I don't think so. You make no sense here. Someone said: I need an editor, I want it do do these things, and he wrote it. Sounds like an editor by design to me. :>I presume that you are not primarily interested in employees who work for :>one week, but those who work for years. As such, vi/emacs will provide :>greater productivity. Finally, if you hired me (not that I could be hired), : :I think you are totally wrong here. I am curious as to how much time you have :spent in the industry. And please look around you and count the number of users :who would like vi/emacs. What choice a UNIX user has got? vi or emacs. Both of :them suck (IN MOST OF THE CASUAL USERS' opnion). The very fact that some time :back we saw a posting about a lynch party going to the systems programmer :asking him to change vi to look like ISPF or Word Perfect is a dead give away. If you only use a computer once a year, then fine. Otherwise, the original poster is right. If you give someone a no-mind editor, you lock them into this poverty-stricken environment, and they'll never advance. At least with vi and emacs you can get by with a small subset of commands. I've taught UNIX for 7 years now, and I've never failed to each anyone vi in an hour or less. :>you would find that my productivity is much higher with vi/emacs than some :>other brain dead editor. : :Get real. Go get a job in the real world. YOU get real. How do you define the real world? Invoking `real world' is just a snide, patronizing way of telling someone you don't think their job is worthwhile. It's rude. And it's got little bearing in reality. Everyone can pick out some other group whose work they consider less important than their own. My productivity is indeed a lot higher with vi than with a brain-dead editor like Wordstar. I know -- I made the transition. It was like a breath of fresh air. I don't like to type. I want to be able to identify common practices, and easily reduce the steps it takes to get those effects. I want to be able to move around in textual units, not arrow keys. I don't want someone holding my hand, supposedly "helping" me. :>Perhaps yours is the answer of someone who only looks two weeks ahead. : :Yours is the answer who has a completely cloistered outlook on life. Oh, stuff it. Cloistered because he doesn't work with people who need child-proof caps and coloring-book pictures for their editors? Who are you teaching, pre-schoolers? --tom
ts@cup.portal.com (Tim W Smith) (03/05/91)
< for next line than "control-N" or j (if you know the ascii code). How can < a programmer not know the Ascii code? Because the vast majority of programmers have no need to know the ASCII code. Tim Smith
joshi@m.cs.uiuc.edu (Anil Joshi) (03/06/91)
tchrist@convex.COM (Tom Christiansen) writes: >:gast@lanai.cs.ucla.edu (David Gast) writes: >: >: >:>>Good God! I do know how to survive using vi and emacs. I've been using >:>>them for months. The point is that a new programmer has an exaggerated >:>>learning curve with these products as opposed to an editor with function >:>>keys defined and use of the full range of keys on the keyboard. >: >:I share his feelings completely. Exaggerated learning curve is not the only >:problem with these editors. They presume that user computing is a myth. Try >:teaching reg.exprs. to an end user. >Say what? You don't HAVE to learn them. Anyone who wants to learn No. If I want to find say some string which includes a . 1. You have to know what is the magic setting 2. You have to know there is such a thing as editor settings. 3. You have to know that . stands for any character in REG. EXPRS. 4. You have to know how to reset magic. The grep command can not be used without reg expr., the substitute can not be used without reg exprs. Why not have two commands for doing? One command says just find wihthout magic, and the other says have all the power of reg exprs. The people who want to do more would learn both, the others are completely insulated from this. They do not have to even know that something called reg.expr. exists. Set magic off by default. >will learn them easily. Trying to force feed them on someone who >doesn't understand why he would want one might have a bad reaction, >but this is such basic stuff that I don't believe anyone who wants >to learn them can't. If so, we have a broom waiting for him. But we are talking about a lot of secretaries here, not programmers. I have done courses in both compilers and automata, I do understand Reg. Exprs. but still feel that they are too complicated for use in editors. Have them by all means (because there is definitely a need for them), but do not force on all. I can give very elegant solutions to a lots of problems which were posted in the past if there were column based editing in addition to reg. exprs. in vi. The very fact that vi can not be extended and enhanced means that it is time we abandon this editor and design a new editor from scratch. It will include the good features from vi, emacs, ISPF etc. but only after a consensus from the users at large. Not somebody just sitting at the terminal and hacking up something that serves his/her purpose. >:What about >: >:map! ^X^C^V&^%? >: >:Is that mnemonic for you? You must be kidding. >It's my keystroke sequence. Once the keystrokes make sense, the >bindings do to. It's not a program language, but big deal. It >does go a long way. You cannot see the key strokes. Like is it a carriage return, a space, a Controlchar. ? Hex editing is very bad in vi. It is handled very well in ISPF. >:Are you talking about speed of editors here or speed of usage? For one, >:emacs is the slowest thing I have seen in my seven years of experience. >Which emacs? There is no One Emacs -- microemacs can be as small as >vi. It doesn't have to be slow. Gnu's is slow on small machines, but It is slow on a big machine which is very heavily loaded. And also, I hate to type with one of my hands permanently attached to ctrl/esc keys. >:vi by no means is an editor by design. Ergonomics is a greek word for the >:designers/supporters/ users of vi. >And what is it then, a mail reader? I don't think so. You make no It is an editor by hacking. >sense here. Someone said: I need an editor, I want it do do these >things, and he wrote it. Sounds like an editor by design to me. That is the problem. How many people were involved in giving the original user specs? Where are the user specs? Where is the test data? Who tested it? What were the design goals? What assumptions were made about the end users? >:I think you are totally wrong here. I am curious as to how much time you have >:spent in the industry. And please look around you and count the number of users >:who would like vi/emacs. What choice a UNIX user has got? vi or emacs. Both of >:them suck (IN MOST OF THE CASUAL USERS' opnion). The very fact that some time >:back we saw a posting about a lynch party going to the systems programmer >:asking him to change vi to look like ISPF or Word Perfect is a dead give away. >If you only use a computer once a year, then fine. Otherwise, the >original poster is right. If you give someone a no-mind editor, you >lock them into this poverty-stricken environment, and they'll never >advance. At least with vi and emacs you can get by with a small subset >of commands. I've taught UNIX for 7 years now, and I've never failed >to each anyone vi in an hour or less. I am not saying that you cannot teach vi. Unfortunately, it boils down to learning UNIX as well. The whole thing does not mesh very well. >YOU get real. How do you define the real world? Invoking `real world' is >just a snide, patronizing way of telling someone you don't think their job >is worthwhile. It's rude. And it's got little bearing in reality. >Everyone can pick out some other group whose work they consider less >important than their own. I do retract ny earlier statement and APOLOGIZE if I had been rude. I do get frustrated on the other hand with people who argue wihtout having seen other things. >My productivity is indeed a lot higher with vi than with a brain-dead >editor like Wordstar. I know -- I made the transition. It was like a I thought that we are talking about program editors here. I do agree that word star/word perfect are brain-dead editors. But I am talking about other editors (ISPF/XEDIT) which I think a lot of users of this forum do like but afraid to say so because they will be ridiculed of liking something from the big blue. >breath of fresh air. I don't like to type. I want to be able to identify >common practices, and easily reduce the steps it takes to get those >effects. I want to be able to move around in textual units, not arrow >keys. I don't want someone holding my hand, supposedly "helping" me. Problem is that when one is editing programs, the textual units are non-existent are have a completely different meaning in each programming language. A good editor should not make any assumptions about the textual units - the user may be editing any thing. Semi-screen editors like ISPF do win because they do not make any assumptions about the textual units. But on the other hand one can define these (through macros) and bind them to function keys and viola, you have the right macros for the right units. Ex. If I am editing a file with .tex as the extension, I get the right macros loaded for this (things like the function key bindings) for text units. If I am editing c programs, the right ones get loaded again. But these should not be limited to only exeisting languages. The editor should be extensible so that new situations can be handled very easily. vi can, by any means, be called an extensible editor. 1. Its arcane macro language. 2. Inability to program the macros + parameterized macros. >:Yours is the answer who has a completely cloistered outlook on life. >Oh, stuff it. Cloistered because he doesn't work with people who >need child-proof caps and coloring-book pictures for their editors? >Who are you teaching, pre-schoolers? I am sorry I made some rude comments in the previous note. I apologize once more. >--tom Anil joshi@cs.uiuc.edu -- "Whatever we wish ourselves to be, we have the power to make ourselves. If what we are now has been the result of our own past actions,then it certainly follows that whatever we wish to be in the future, can be produced by our own present actions." - Vivekananda, Late Nineteenth Century Indian Philosopher
tchrist@convex.COM (Tom Christiansen) (03/06/91)
From the keyboard of joshi@m.cs.uiuc.edu (Anil Joshi): :Set magic off by default. Easily done. In fact, when invoked as `edit', this is the default. :>:What about :>: :>:map! ^X^C^V&^%? :>: :>:Is that mnemonic for you? You must be kidding. : :>It's my keystroke sequence. Once the keystrokes make sense, the :>bindings do to. It's not a program language, but big deal. It :>does go a long way. : :You cannot see the key strokes. Like is it a carriage return, a space, a Controlchar. ? Hex editing is very bad in vi. It is handled very well in ISPF. What is hex editing? I freely admit that the vi macro language is in a sense arcane, but only because it directly reflects the command language. Better than Pmate, which if I recall had two archaic sets, one for editing, one for programming the macros. At least emacs's macros are in a semi-recognizable programming language. :That is the problem. How many people were involved in giving the original :user specs? Where are the user specs? Where is the test data? Who tested it? :What were the design goals? What assumptions were made about the end users? Who's been feeding you this story? It's a myth that this is the right way to produce excellent software. It just slows down it's completion by an order or two of magnitude, and it doesn't produce better results. In fact, they're often worse: design by committee sucks. Excellent software is the crystalization of one unified vision. It is usually written by one or two programmers working for 1-6 months, a year tops. You discuss the rough goals, find good people, and give them free reign. Then when it's done you go back and fine tune. Otherwise you get garbage. :I am not saying that you cannot teach vi. Unfortunately, it boils down to :learning UNIX as well. The whole thing does not mesh very well. Only to do the powerful things, like regexps, region filters, etc. :I do retract ny earlier statement and APOLOGIZE if I had been rude. Accepted. :I thought that we are talking about program editors here. I do agree that :word star/word perfect are brain-dead editors. But I am talking about other :editors (ISPF/XEDIT) which I think a lot of users of this forum do like but :afraid to say so because they will be ridiculed of liking something from the :big blue. Xedit was icky because of the darn 3270 terminals. Its integrated command language did take an interesting approach. Certainly better than Wordstar, but this is little comparison. In a way, it was reminiscent of shell escapes and filter pipes, right? You could right XEDIT macros in REXX, couldn't you? Isn't that like writing vi macros that call shell scripts? :Problem is that when one is editing programs, the textual units are :non-existent are have a completely different meaning in each programming :language. A good editor should not make any assumptions about the textual :units - the user may be editing any thing. It may be that the emacs's modes take care of this by being able to recognize the type of file and adjust itself accordingly, giving you something of a syntax-directed editor. I work in C and languages resembling C (perl, C++), so I really appreciate the C features. I agree that vi's method of having hardwired knowledge of C and lisp is sub-optimal, but it's better than nothing. I also work in troff a lot, so I like its knowledge not just of words, sentences, and paragraphs, but also the paragraphs and sections according to the dot commands you use, which you can redefine. I know this is old technology, but it sure works for what I need to use it for. Take away my sentence and paragraph region commands when editing things like this, and I will not be happy. :Semi-screen editors like ISPF I begin to sense religion. DO you think you will somehow make the world a better place by making them all learn this editor you keep referencing? I don't know it, so can't make comparisons, so I'll leave that up to someone else. But I can't believe you'd make me more productive by making me use it instead of my highly-tuned, integrated environment I've worked up over years of tinkering. :do win because they do not make any assumptions about the textual units. But :on the other hand one can define these (through macros) and bind them to :function keys and viola, you have the right macros for the right units. viola? violin? ah, voila, as in voici. I get it now. :-) :Ex. If I am editing a file with .tex as the extension, I get the right macros :loaded for this (things like the function key bindings) for text units. : :If I am editing c programs, the right ones get loaded again. But these should :not be limited to only existing languages. The editor should be extensible :so that new situations can be handled very easily. vi can, by any means, be :called an extensible editor. you mean cannot. i'd call it crudely programmable. you can easily set up a script that looks at the file extension and loads the right bindings by setting the EXINIT variable. and certainly emacs can do this with ease. i think even microemacs, the fast one, although i'm not sure. :1. Its arcane macro language. As I've said, this is just its editing language. So? :2. Inability to program the macros + parameterized macros. what do you mean program the macros? i understand the parameterization thing. we're just talking key-bindings, not program-controlled macros. you want a language? either make shell escapes or use emacs. i don't see that it requires a whole new editor. btw, i wouldn't say that unix users can count on having vi and emacs. i'd say they can only count on vi. there are too many kinds of emaxen, and they're not always there. it's been that way for a long time, which is why 1003.2 chose ex and vi as the editor that must be present on a conforming system. minimal fluency in them is really a good idea even if you use something else as your primary editor, if for no other reason because they are guaranteed to be there. --tom
new@ee.udel.edu (Darren New) (03/06/91)
In article <1991Mar05.205629.24743@convex.com> tchrist@convex.COM (Tom Christiansen) writes: >Better than Pmate, which if I recall had two archaic >sets, one for editing, one for programming the macros. Actually, I used PMate for several years and I really liked it. If I recall, there was no archaic (I think you mean arcane) language for "editing" (which I take you to mean interactive work). The key bindings were attached to sequences of macro commands just as in vi or emacs; I don't remember if rebinding was possible because I never did it (working with too many other people). I'll grant that the macro language was kind of ugly, but it was much better for short macros than either vi's (which is too limited) or emacs' (which is too wordy). It was sufficiently powerful to write arcade games in :-) as well as lots of useful stuff. And it fit in 64K along with unlimited size files, which is more than I can say for emacs as well. Actually, now that I think about it, the editting macros seemed to be based on TECO, which at this point is pretty archaic. :-) -- --- Darren New --- Grad Student --- CIS --- Univ. of Delaware --- ----- Network Protocols, Graphics, Programming Languages, Formal Description Techniques (esp. Estelle), Coffee, Amigas ----- =+=+=+ Let GROPE be an N-tuple where ... +=+=+=
dylan@ibmpcug.co.uk (Matthew Farwell) (03/06/91)
In article <1991Mar5.060746.10973@m.cs.uiuc.edu> joshi@m.cs.uiuc.edu (Anil Joshi) writes: >gast@lanai.cs.ucla.edu (David Gast) writes: >>In article <1991Jan30.224717.6150@bradley.bradley.edu> larry@bradley.bradley.edu (Larry D. Stratton) writes: >>>Good God! I do know how to survive using vi and emacs. I've been using >>>them for months. The point is that a new programmer has an exaggerated >>>learning curve with these products as opposed to an editor with function >>>keys defined and use of the full range of keys on the keyboard. >I share his feelings completely. Exaggerated learning curve is not the only >problem with these editors. They presume that user computing is a myth. Try >teaching reg.exprs. to an end user. I have actually. To quite a few, from cs students to normal users. They were generally:- 1) Surprised at how powerful reg. exps were 2) Amazed at how they survived without them. So how does this wonderful ISPF do pattern matching then? I've also taught people how to use vi. Mostly the reactions were variations on 'I didn't know vi could do that, thats ded good' >>you would find that my productivity is much higher with vi/emacs than some >>other brain dead editor. >Get real. Go get a job in the real world. And how do you know he hasn't got a job in the real world? How do you know that he hasn't been writing editors for the last 20 years? If I were David Gast, I'd find your above statement quite insulting. Whats more important, we don't know *your* background history. Could we please know a bit more. I'd also like to know how ISPF does all these wonderful things, which are obviously *so* easy to learn and use, according to you. Lets have some explanations please... Take it to email if nobody else is interested... Dylan. -- Matthew J Farwell: dylan@ibmpcug.co.uk || ...!uunet!ukc!ibmpcug!dylan If you've ever wondered how to get triangles from a cow, you need butter, milk and cheese and an equilateral chainsaw.
xiaoy@ecf.toronto.edu (XIAO Yan) (03/06/91)
> >What about > >map! ^X^C^V&^%? > >Is that mnemonic for you? You must be kidding. > When you're thinking of doing those mappings, obviously you're not a naive user and I cannot see why you are complaining? I would suggest you just to remember move-around-commands and simple- minded-commands. The more you read vi/ex manual, the more you would complain. Just 2 cents to align with vi-lovers. Xiao
les@chinet.chi.il.us (Leslie Mikesell) (03/06/91)
In article <1991Mar5.184647.28175@m.cs.uiuc.edu> joshi@m.cs.uiuc.edu (Anil Joshi) writes: >>:>>Good God! I do know how to survive using vi and emacs. [re: regexps] >>Say what? You don't HAVE to learn them. Anyone who wants to learn >No. If I want to find say some string which includes a . >1. You have to know what is the magic setting >2. You have to know there is such a thing as editor settings. >3. You have to know that . stands for any character in REG. EXPRS. >4. You have to know how to reset magic. No, all you have to know is that the '\' character removes the magic properties from the following character in vi just like it does in the shell and many other places in unix (e.g. the tty driver itself). I don't see how you can survive long without learning this, because you will certainly need to manipulate the '\' character itself at some point. /\./ will find a period. >The grep command can not be used without reg expr., the substitute can not be >used without reg exprs. Why not have two commands for doing? One command says >just find wihthout magic, and the other says have all the power of reg exprs. If you like single character commands (I do) you will find that there aren't enough of them to make two versions of every command. Besides, why do you think that people who aren't willing to learn the basics would want to deal with twice as many commands? Les Mikesell les@chinet.chi.il.us
peter@ficc.ferranti.com (Peter da Silva) (03/07/91)
In article <39861@cup.portal.com> ts@cup.portal.com (Tim W Smith) writes: > Because the vast majority of programmers have no need to know the ASCII > code. Exactly right. The vast majority of programmers are coding in COBOL on machines that use EBCDIC. -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"
joshi@m.cs.uiuc.edu (Anil Joshi) (03/07/91)
xiaoy@ecf.toronto.edu (XIAO Yan) writes: >> >>What about >> >>map! ^X^C^V&^%? >> >>Is that mnemonic for you? You must be kidding. >> >When you're thinking of doing those mappings, obviously you're not a >naive user and I cannot see why you are complaining? >I would suggest you just to remember move-around-commands and simple- >minded-commands. The more you read vi/ex manual, the more you would >complain. >Just 2 cents to align with vi-lovers. My complaint is not with the mapping. I don't want you to take away even that minimal functionality from vi. Then vi would be nothing (an empty shell :-)). Any way, see a couple of postings previous to this about not being able to detect what the control sequence is. There are all kinds of suggegstions about going to the ^ and see whether the cursor jumps one space or two spaces etc. This is kludgyness at its best. Clearly the problem lies with the way the vi commands work. This is a very fundamental problems, IMHO. >Xiao you people like this editor and support it. That's fine. But please do accept that this is old technology and should not have been made the POSIX standard in hundred years. That's a real shame. :-( Anil joshi@cs.uiuc.edu -- "Whatever we wish ourselves to be, we have the power to make ourselves. If what we are now has been the result of our own past actions,then it certainly follows that whatever we wish to be in the future, can be produced by our own present actions." - Vivekananda, Late Nineteenth Century Indian Philosopher
tchrist@convex.COM (Tom Christiansen) (03/07/91)
From the keyboard of joshi@m.cs.uiuc.edu (Anil Joshi): :you people like this editor and support it. That's fine. But please do accept :that this is old technology and should not have been made the POSIX standard :in hundred years. That's a real shame. :-( If in a hundred years the POSIX standard were vi, that would be a crime. However, at this point in history, POSIX is not trying to come up with better software (nor can they -- they're a committee). Rather, they're trying to standardize on existing practices. There was no other editor than vi that could have fulfilled this requirement. --tom -- I get so tired of utilities with arbitrary, undocumented, compiled-in limits. Don't you? Tom Christiansen tchrist@convex.com convex!tchrist
joshi@m.cs.uiuc.edu (Anil Joshi) (03/08/91)
dylan@ibmpcug.co.uk (Matthew Farwell) writes: >>>you would find that my productivity is much higher with vi/emacs than some >>>other brain dead editor. >>Get real. Go get a job in the real world. >And how do you know he hasn't got a job in the real world? >How do you know that he hasn't been writing editors for the last 20 years? >If I were David Gast, I'd find your above statement quite insulting. I already apologized to David Gast on the net about my rude comments. There was an implied meaning in the above statement about brain-dead editors - that the users who use them also brain-dead. If a person has contemp for the users then most probably that person has not worked with users before. In the industry, a programmer's job is to keep the end users happy, because the salary of the programmer comes out of user department's budget. They hold the purse strings. >Whats more important, we don't know *your* background history. Could we >please know a bit more. I'd also like to know how ISPF does all these Sure. I programmed for seven years on the following - 1. IBM Mainframes - IBM 3090, 3081 etc. with MVS/XA and VM/CMS, TSO/CLISTs, REXX, DB2, IMS, Assembly, PL/I, COBOL etc. 2. DEC PDP/11 - RSTS/E 3. Burroughs B5700, B5900, B1900, B20, A9, A3, MCP 6.0, DMS-II, COBOL, ALGOL 4. Stratus VOS, Pascal 5. IBM PCs >wonderful things, which are obviously *so* easy to learn and use, according >to you. Lets have some explanations please... Take it to email if nobody else >is interested... I think that explanation is not necessary because you might have already seen some of the people who worked on IBM mainframes miss not only the ISPF editor but ISPF itself. It is more intuitive and user friendly. I have to agree though that the pattern matching facilities in the base ISPF editor are not good. But this problem is easily solved by resorting to macros which can be written in a full functional language like TSO/E CLIST or REXX languages. By the way, REXX has quite a few powerful features for doing pattern matching, building and executing arbitrary statements (it has interpret instruction), and recently pipes etc. It's syntax also is more intuitive than the UNIX shell languages. Anil -- "Whatever we wish ourselves to be, we have the power to make ourselves. If what we are now has been the result of our own past actions,then it certainly follows that whatever we wish to be in the future, can be produced by our own present actions." - Vivekananda, Late Nineteenth Century Indian Philosopher
joshi@m.cs.uiuc.edu (Anil Joshi) (03/08/91)
les@chinet.chi.il.us (Leslie Mikesell) writes: >No, all you have to know is that the '\' character removes the >magic properties from the following character in vi just like it >does in the shell and many other places in unix (e.g. the tty driver >itself). I don't see how you can survive long without learning this, >because you will certainly need to manipulate the '\' character itself >at some point. > /\./ will find a period. That's a constant annoyance. Try to count the number of meta-chars you have to type verses what you have to type if you have two sets of commands. /\.\^\$\$\=\\ vs f .^$$=\ >>The grep command can not be used without reg expr., the substitute can not be >>used without reg exprs. Why not have two commands for doing? One command says >>just find wihthout magic, and the other says have all the power of reg exprs. >If you like single character commands (I do) you will find that there aren't >enough of them to make two versions of every command. Besides, why do you >think that people who aren't willing to learn the basics would want to >deal with twice as many commands? People are willing to learn basics, but why are forcing them to learn more than just the basics? In your model, people have to learn everything or run to a guru a lot of times. In my model, if they do not find the guru, they can still do it the hard way. At least they can get it going. Anyway, where are these reg.exprs. explained? Each utility has its own conventions for reg.exprs. Why? Why not have a common explanation somewhere and all new programs stick to it? Define a minimal set plus extras. No such thing exists in UNIX world today. In my opinion, most of the ills of vi are directly inherited from UNIX. >Les Mikesell > les@chinet.chi.il.us Anil -- "Whatever we wish ourselves to be, we have the power to make ourselves. If what we are now has been the result of our own past actions,then it certainly follows that whatever we wish to be in the future, can be produced by our own present actions." - Vivekananda, Late Nineteenth Century Indian Philosopher
tchrist@convex.COM (Tom Christiansen) (03/08/91)
From the keyboard of joshi@m.cs.uiuc.edu (Anil Joshi): :but ISPF itself. It is more intuitive and user friendly. user friendly == programmer hostile I've yet to find a "user friendly" program that pleased both naive users and also software professionals. :I have to agree though :that the pattern matching facilities in the base ISPF editor are not good. But :this problem is easily solved by resorting to macros which can be written in a :full functional language like TSO/E CLIST or REXX languages. By the way, REXX :has quite a few powerful features for doing pattern matching, building and :executing arbitrary statements (it has interpret instruction), and recently :pipes etc. It's syntax also is more intuitive than the UNIX shell languages. This is religion here. Why don't you go back to IBM where you're obviously so much happier and stop trying to foist your religion on those already happy and productive with UNIX? I've used REXX for non-trivial things, and while it does indeed offer features that the vintage uNIX shell doesn't, there are a lot of other things that have come out in the last 15 years. These tend to be four-letter words, but do be it. --tom -- I get so tired of utilities with arbitrary, undocumented, compiled-in limits. Don't you? Tom Christiansen tchrist@convex.com convex!tchrist
tchrist@convex.COM (Tom Christiansen) (03/08/91)
From the keyboard of joshi@m.cs.uiuc.edu (Anil Joshi): :Anyway, where are these reg.exprs. explained? In the vi manual. In the ed manual. In the regex(3) man page. In the grep(1) man page. I begin to wonder how long Mr. Joshi has actually been working with UNIX. --tom -- I get so tired of utilities with arbitrary, undocumented, compiled-in limits. Don't you? Tom Christiansen tchrist@convex.com convex!tchrist
xiaoy@ecf.toronto.edu (XIAO Yan) (03/08/91)
> (lines deleted) >you people like this editor and support it. That's fine. But please do accept >that this is old technology and should not have been made the POSIX standard >in hundred years. That's a real shame. :-( > (lines deleted) In my opinion, the command structure (or rather, the interface structre) of UNIX puts line break (RETURN) a promenent position and therefore vi and emacs are therefore technology that goes with OS. These line-based editors work well with OS. I really cannot see how you manage a UNIX system well without knowing vi. As philosophers say, behaviour complexity is a mirror image of complexity of reality. If you find vi too complicated, then reduce the needs of complexity at the first place. Xiao
gast@maui.cs.ucla.edu (David Gast) (03/08/91)
In article <1991Mar5.060746.10973@m.cs.uiuc.edu> joshi@m.cs.uiuc.edu (Anil Joshi) writes: >gast@lanai.cs.ucla.edu (David Gast) writes: >>In article <1991Jan30.224717.6150@bradley.bradley.edu> larry@bradley.bradley.edu (Larry D. Stratton) writes: >I share his feelings completely. Exaggerated learning curve is not the only >problem with these editors. They presume that user computing is a myth. Try >teaching reg.exprs. to an end user. I thought we were talking about editors for programmers. Any programmer who cannot handle regular expressions must not be a very good programmer. Even the secretaries in our department can handle regular expressions. Anyway, I would not be caught dead using an editor without them. >I think you are totally wrong here. I am curious as to how much time you have >spent in the industry. And please look around you and count the number of users >who would like vi/emacs. What choice a UNIX user has got? vi or emacs. Both of >them suck (IN MOST OF THE CASUAL USERS' opnion). The very fact that some time >back we saw a posting about a lynch party going to the systems programmer >asking him to change vi to look like ISPF or Word Perfect is a dead give away. There is also the rand editor now called the grand editor. It is on our system although I don't know anyone who uses it. The same goes with some editor which is part of Sun Tools. Most programmers are not casual users. If I had to use ISPF or Word Perfect, I would want it to look like vi or emacs, what does that prove? On my PC, I only have vi (Well, I guess edlin is on there too). It's all I need. >>you would find that my productivity is much higher with vi/emacs than some >>other brain dead editor. >Get real. Go get a job in the real world. How can you speak for me? I said my productivity. I've had jobs in the real world and I don't know of an editor that is faster for me than vi. Anyway, your account seems to be at U of I is that any more of the real world than UC? But I will dismiss the rest of the personal attack. I've used lots of other editors--vi was the at least the fifth one I learned. David
gast@maui.cs.ucla.edu (David Gast) (03/08/91)
In article <1991Mar5.184647.28175@m.cs.uiuc.edu> joshi@m.cs.uiuc.edu (Anil Joshi) writes: >tchrist@convex.COM (Tom Christiansen) writes: >>:gast@lanai.cs.ucla.edu (David Gast) writes: Concerning regular expressions: >No. If I want to find say some string which includes a . >1. You have to know what is the magic setting >2. You have to know there is such a thing as editor settings. >3. You have to know that . stands for any character in REG. EXPRS. >4. You have to know how to reset magic. Set it up one way. Take your pick, but I suggest with magic. Then all you have to know for period is to type \. Is that so difficult? It is any worse than * in the shell? It means there is only one step to learn. Further, unless you are trying to find only a period, a string like "end of sentence. Beginning of sentence here" can be found easily with "/ce. " So the user may have to type n once or twice. Big deal. Further, this dot problem also affects grep and awk and sed and a lot of other programs. You don't use them? How do you teach grep without teaching regular expressions? Do you know what grep stands for? "global regular expression and print" It is straight from "ed". >I can give very elegant solutions to a lots of problems which were posted >in the past if there were column based editing in addition to reg. exprs. in >vi. I am not exactly sure what you mean by column based editing. One solution is to have vi automatically change rotate the text by -90 on entry, then edit normally, and have vi automatically rotate the text by -90 degrees when finished. I suspect you have something else in mind. There is the | command which goes to a specified column. You can set up other features with macros or bind a function key to a vi sequence and a shell script or c program. >The very fact that vi can not be extended and enhanced means that it is >time we abandon this editor and design a new editor from scratch. vi is somewhat extensible with macros, emacs is very extensible. Is ISPF extensible? What about Word Perfect? (The two editors you mention). How do I get vi mode in ISPF? How do I get regular expressions? The fact that vi can call any other program makes it as extensible as the entire Unix operating system. What more do you want? >It will >include the good features from vi, emacs, ISPF etc. but only after a consensus >from the users at large. Not somebody just sitting at the terminal and >hacking up something that serves his/her purpose. It is impossible to get all users to agree on features. There will be no consensus. >>:Are you talking about speed of editors here or speed of usage? For one, >>:emacs is the slowest thing I have seen in my seven years of experience. I stated very clearly speed of usage. But there are small emacs that run fast. >That is the problem. How many people were involved in giving the original >user specs? Where are the user specs? Where is the test data? Who tested it? >What were the design goals? What assumptions were made about the end users? You would have to ask the people at Bell Labs. vi and ex are just extensions of ed. Anyway, are you really convinced that an editor designed by committee with be small, effective, and fast? >I am not saying that you cannot teach vi. Unfortunately, it boils down to >learning UNIX as well. The whole thing does not mesh very well. This is a really curious statement unless you believe that you should have one sort program when using Perfect Editor and another sort program an user interface when using Perfect DB and another sort program and user interface when using Perfect SpreadSheet, etc. >I do get >frustrated on the other hand with people who argue wihtout having seen other >things. I have seen other things. Did you read what I posted? So as Tom. >editors (ISPF/XEDIT) which I think a lot of users of this forum do like but >afraid to say so because they will be ridiculed of liking something from the >big blue. I've used XEDIT. I prefer vi. I used XEDIT for at least three years before I learned vi. I knew XEDIT better than anyone else that I knew. >Ex. If I am editing a file with .tex as the extension, I get the right macros >loaded for this (things like the function key bindings) for text units. You can do this with a simple shell script and vi or just vi if you want to do it manually. >2. Inability to program the macros + parameterized macros. Yes, it would be easier to use if there were parameters and a few other features. I would support your adding them. I do not, however, want to throw the baby out with the bath water. David
mroussel@alchemy.chem.utoronto.ca (Marc Roussel) (03/09/91)
In article <1991Mar07.232206.8438@convex.com> tchrist@convex.COM (Tom Christiansen) writes: >From the keyboard of joshi@m.cs.uiuc.edu (Anil Joshi): >:Anyway, where are these reg.exprs. explained? > >In the vi manual. In the ed manual. In the regex(3) man page. In the >grep(1) man page. I begin to wonder how long Mr. Joshi has actually been >working with UNIX. Anil's point was that many Unix utilities use different flavours of regular expressions. I for one find that to be a nuisance too. Why should grep use different syntax for its regular expressions than ex? (I know they're quite similar, but at least on our system, they're not identical as far as I can make out from the man pages. Luckily, I've only run into the subtleties once or twice.) Marc R. Roussel mroussel@alchemy.chem.utoronto.ca
ed@lvw6.lvw.loral.com (Ed Allen) (03/10/91)
Why don't you just set 'nomagic' then the special meaning goes away. If you want it back, use '\' before the character: /.\.\*./ will find a line with two periods on it. -- Never trust a man who wears white shoes. | Ed Allen Vote Libertarian... Scare the Hell out of 'em. | Loral Command & Contr. Sys.
ts@cup.portal.com (Tim W Smith) (03/10/91)
>> Because the vast majority of programmers have no need to know the ASCII >> code. > >Exactly right. The vast majority of programmers are coding in COBOL on >machines that use EBCDIC. No, the vast majority are using modern languages where the compiler handles translating things like 'a' into the appropriate ASCII code (or EBCDIC code if that's what the machine uses). Unless you program like this: unsigned char main[] = { 12, 17, 97, 243, 122 }; you rarely need to know ASCII codes. Tim Smith
les@chinet.chi.il.us (Leslie Mikesell) (03/11/91)
In article <1991Mar7.214419.17515@m.cs.uiuc.edu> joshi@m.cs.uiuc.edu (Anil Joshi) writes: [backslash forces literal in regexp] >That's a constant annoyance. Try to count the number of meta-chars you have to >type verses what you have to type if you have two sets of commands. But you do have two sets of commands: set nomagic operation vs. set magic operation This is what you were complaining about in the first place as I recall. Use an appropriate mapping if you think there is an easier way to do it. >Anyway, where are these reg.exprs. explained? Each utility has its own >conventions for reg.exprs. Why? Why not have a common explanation somewhere >and all new programs stick to it? Define a minimal set plus extras. No such >thing exists in UNIX world today. In my opinion, most of the ills of vi are >directly inherited from UNIX. Now you've hit the real problem, and one that does not have any simple solution. Note the resemblance to the problems with human languages. Where are the rules explained? Why are there exceptions? Unix utilities have evolved into their current form without a single point of control that can make decisions like that. And if someone did try to force regexps into a "lowest-common-denominator" model, the utilities affected would just be avoided and people would use an add-on utility like perl with useful extensions. Note more carefully what you say about vi inheriting things from unix, though, keeping in mind that the original set of users were unix programmers and you will see that it actually made it more intuitive. Also, the original users of unix had access to the source (and the authors) of everything. Unfortunately, this is still reflected in the lack of documentation. Les Mikesell les@chinet.chi.il.us
xiaoy@ecf.toronto.edu (XIAO Yan) (03/12/91)
In article <40012@cup.portal.com> ts@cup.portal.com (Tim W Smith) writes: (lines deleted) >handles translating things like 'a' into the appropriate ASCII code >(or EBCDIC code if that's what the machine uses). > >Unless you program like this: > > unsigned char main[] = { 12, 17, 97, 243, 122 }; > >you rarely need to know ASCII codes. Can't you define macros to generate those nice ASCII codes if your personal taste prefers? Above all, 'a' is not so professional as 97 :-). Xiao
meissner@osf.org (Michael Meissner) (03/13/91)
In article <40012@cup.portal.com> ts@cup.portal.com (Tim W Smith) writes: | >> Because the vast majority of programmers have no need to know the ASCII | >> code. | > | >Exactly right. The vast majority of programmers are coding in COBOL on | >machines that use EBCDIC. | | No, the vast majority are using modern languages where the compiler | handles translating things like 'a' into the appropriate ASCII code | (or EBCDIC code if that's what the machine uses). | | Unless you program like this: | | unsigned char main[] = { 12, 17, 97, 243, 122 }; | | you rarely need to know ASCII codes. Or unless you build an array which uses the character code as an index (ie, you want to say array[ch] where ch = 'a', and array is initialized statically). -- Michael Meissner email: meissner@osf.org phone: 617-621-8861 Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142 Considering the flames and intolerance, shouldn't USENET be spelled ABUSENET?
torek@elf.ee.lbl.gov (Chris Torek) (03/18/91)
In article <1991Mar8.164415.14087@alchemy.chem.utoronto.ca> mroussel@alchemy.chem.utoronto.ca (Marc Roussel) writes: >Anil's point was that many Unix utilities use different flavours of >regular expressions. I for one find that to be a nuisance too. Why >should grep use different syntax for its regular expressions than ex? This is fixed in 10th Edition Unix. It is just an accident of history. There *is* a reason for some difference, actually: Editors must have a way of marking matches for substitutions, while pure matchers (grep) do not need this. Things might be in much better shape if Ken Thompson had originally designed `ed' with a single special character that introduced all regular expression metasequences; then existing programs (and people!) that use the various RE matchers would already quote that character and it would not be such a problem to change them all to have some new feature. For instance, if `_' were the magic character, then: grep stdio.h *.c would do what you meant; you would have to ask for grep '#_ _*include_ _*<_._*>' to match `#, followed by any amount of space, followed by include, followed by any amount of space, followed by <, followed by any amount of anything except newline, followed by >'. Here `_ ' means `space or tab' and is just shorthand for _[ _]. `Remembering' for replacements could be done with _(foo_) and back-references with _1 through _9. You could also get rid of the positional requirements for - and ^ within character classes (I got rid of the one for ] already, above, by using _]) by using _- and _^: _[^a_-zA_-Z-_] would mean `class: caret, or a through z, or A through Z, or hyphen', which matches things like `word' or `hyphenated-word' and includes words spelled `r^ole'. To match everything but that, throw _^ in somewhere. (Now someone will argue for something other than `_'... :-) Backslash would be good, but the shell uses it; that is why I picked _ here.) (Actually, if I were designing an RE syntax, I think I would make Kleene `*' matching use a prefix, not a postfix; it means something like foo\* bar would match `foobar' and `foo bar'. I think of * as `zero or more', so this means "foo, zero or more o's, bar". \+X for 1 or more X, and \<m,n>X for `between m and n inclusive' X's, would also be useful.) -- In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427) Berkeley, CA Domain: torek@ee.lbl.gov
larry@st-andy.uucp (Larry Martell) (03/20/91)
In article <39861@cup.portal.com> ts@cup.portal.com (Tim W Smith) writes: >< for next line than "control-N" or j (if you know the ascii code). How can >< a programmer not know the Ascii code? > >Because the vast majority of programmers have no need to know the ASCII >code. > Because the vast majority of programmers have no idea how the underlying machine works is why there are so many poor programmers. -- Larry Martell uunet!st-andy!larry 212-668-9478
ronald@robobar.co.uk (Ronald S H Khoo) (03/27/91)
torek@elf.ee.lbl.gov (Chris Torek) writes: > Things might be in much better shape if Ken Thompson had originally > designed `ed' with a single special character that introduced all > regular expression metasequences; Perl does this with '\'. Nice. Problem is I keep typing Perl-style patterns at other utilities, now :-( > (Actually, if I were designing an RE syntax, I think I would make Kleene > `*' matching use a prefix, Yuck. I vaguely remember an editor embedded in some language product that ran on a micro (was it a BBC ? can't remember) doing something like this and I *hated* it. WHAT? You mean I gotta know what I want to repeat *before* I type it? Ugh. -- Ronald Khoo <ronald@robobar.co.uk> +44 81 991 1142 (O) +44 71 229 7741 (H)
freek@fwi.uva.nl (Freek Wiedijk) (03/28/91)
In article <11036@dog.ee.lbl.gov> torek@elf.ee.lbl.gov (Chris Torek) writes: >Things might be in much better shape if Ken Thompson had originally >designed `ed' with a single special character that introduced all >regular expression metasequences; I always thought that `ed' had been written by Kernighan (because he wrote the manual). Can anyone tell me the history of `ed'? It is my favorite editor! Freek "the Pistol Major" Wiedijk E-mail: freek@fwi.uva.nl #P:+/ = #+/P?*+/ = i<<*+/P?*+/ = +/i<<**P?*+/ = +/(i<<*P?)*+/ = +/+/(i<<*P?)**
soh@andromeda.trl.OZ.AU (kam hung soh) (06/01/91)
I had been using both emacs and vi for the past eight months; emacs for
heavy duty text processing and vi for fixing small glitches. After
modifying my .exrc using tips from this newsgroup, I decided to dump
emacs and use vi exclusively.
"I need the memory and extra CPU time," I told myself.
It was a horrible experience. No multiple files / views / buffers, no
cut-and-paste between windows, no auto auto-indent for the code (yes,
vi had shiftwidth and autoindent, but it's not in the same league as
emacs), no warnings if I stuffed up my scope symbols.
So, I'm back to my old setup with emacs and vi. My opinions about the
constant vi vs. emacs war are:
1. vi is unbeatable for fixing files. It is fast and small, the cursor
whizzes along if I know what I am looking for.
2. emacs is best for large editing jobs. It has the appropriate checks
for scope symbols ( { and }, \begin and \end, etc.) and plenty of
editing functions.
Maybe what I need is vimacs ....
Regards,
------------
Soh, Kam Hung email: h.soh@trl.oz.au tel: +61 3 541 6403
Telecom Research Laboratories, POB 249 Clayton, Victoria 3168, Australia Dan_Jacobson@ATT.COM (06/01/91)
>>>>> On 1 Jun 91 02:15:05 GMT, soh@andromeda.trl.OZ.AU (kam hung soh) said:
kam> So, I'm back to my old setup with emacs and vi.
kam> Maybe what I need is vimacs ....
Try emacs' vi emulation. Do ESC x vip
and also get into emacs' info reader (C-h i) and read
"* VIP: (vip). A VI-emulation for Emacs."melling@cs.psu.edu (Michael D Mellinger) (06/02/91)
In article <1991Jun1.113702.410@cbfsb.att.com> Dan_Jacobson@ATT.COM writes:
kam> So, I'm back to my old setup with emacs and vi.
kam> Maybe what I need is vimacs ....
Try emacs' vi emulation. Do ESC x vip
and also get into emacs' info reader (C-h i) and read
"* VIP: (vip). A VI-emulation for Emacs."
That wasn't his complaint. I think it was something to the effect
that Emacs was big and slow. Launching Emacs for little jobs isn't
quite fast enough unless you have a fast machine.
Is there a another program available besides Emacs client that will
create an Emacs subprocess in the current window? In other words, I
want to start Emacs then type ec and have an Emacs buffer running in
my current window.
-Mikeguy@auspex.auspex.com (Guy Harris) (06/02/91)
>Try emacs' vi emulation.
Which may not fix the problems I infer he had with EMACS; I infer that
EMACS was too slow to start up and run if he only wanted to make a small
fix to a file.soh@andromeda.trl.OZ.AU (kam hung soh) (06/03/91)
Dan_Jacobson@ATT.COM writes: >>>>>> On 1 Jun 91 02:15:05 GMT, soh@andromeda.trl.OZ.AU (kam hung soh) said: >Try emacs' vi emulation. Do ESC x vip >and also get into emacs' info reader (C-h i) and read >"* VIP: (vip). A VI-emulation for Emacs." I had a go at VIP, and it emulates vi very well (right down to the single undo vi offers(!)). However, in the interests of speed and perversity, I decided to have a go at ``ed'' for doing tiny-weeny fixes. ;-->> Regards, Soh, Kam Hung email: h.soh@trl.oz.au tel: +61 3 541 6403 Telecom Research Laboratories, POB 249 Clayton, Victoria 3168, Australia
gvr@cs.brown.edu (George V. Reilly) (06/03/91)
In article <1991Jun2.224020.9490@trl.oz.au> soh@andromeda.trl.OZ.AU (kam hung soh) writes: # Dan_Jacobson@ATT.COM writes: # # >>>>>> On 1 Jun 91 02:15:05 GMT, soh@andromeda.trl.OZ.AU (kam hung soh) said: # # >Try emacs' vi emulation. Do ESC x vip # >and also get into emacs' info reader (C-h i) and read # >"* VIP: (vip). A VI-emulation for Emacs." # # I had a go at VIP, and it emulates vi very well (right down to the # single undo vi offers(!)). Not true. VIP offers multiple undo (`u' followed by as many `.'s as you need to get back to a safe state). Aamod Sane recently posted a revised version of VIP which is closer to the original vi. ________________ George V. Reilly `VIP in my own mind' gvr@cs.brown.edu +1 (401) 863-7684 uunet!brunix!gvr gvr@browncs.bitnet Box 1910, Brown U, Prov, RI 02912
wyle@inf.ethz.ch (Mitchell Wyle) (06/03/91)
In <1991Jun1.021505.4043@trl.oz.au> soh@andromeda.trl.OZ.AU (kam hung soh) writes: >2. emacs is best for large editing jobs. It has the appropriate checks >for scope symbols ( { and }, \begin and \end, etc.) and plenty of >editing functions. Check out the vi % command. It checks the scope of braces, parenthesis, etc.
les@chinet.chi.il.us (Leslie Mikesell) (06/03/91)
In article <1991Jun1.021505.4043@trl.oz.au> soh@andromeda.trl.OZ.AU (kam hung soh) writes: >[...] I decided to dump emacs and use vi exclusively. >It was a horrible experience. No multiple files / views / buffers, no >cut-and-paste between windows, no auto auto-indent for the code You can, of course, run multiple vi's under any windowing system that allows it, and use the windowing system's cut and paste if you prefer it to explicit tmp files (I don't, except when one of the windows is running something that doesn't know how to use files or the programs in the different windows don't share a common filesystem). You can also use an external program to auto-indent or whatever else you need to do. >1. vi is unbeatable for fixing files. It is fast and small, the cursor >whizzes along if I know what I am looking for. >2. emacs is best for large editing jobs. It has the appropriate checks >for scope symbols ( { and }, \begin and \end, etc.) and plenty of >editing functions. >Maybe what I need is vimacs .... I suspect that emacsclient is what you need if you can afford to keep an emacs running all the time. I'm surprised that no one has made a mini-emacs that handled simple editing functions (only), but could save its state and start up big-brother-GNU without losing your place if you decide you want to do something more complicated. Les Mikesell les@chinet.chi.il.us
enag@ifi.uio.no (Erik Naggum) (06/04/91)
Leslie Mikesell <les@chinet.chi.il.us> writes: | | In article <1991Jun1.021505.4043@trl.oz.au> soh@andromeda.trl.OZ.AU (kam hung soh) writes: | >[...] I decided to dump emacs and use vi exclusively. | >It was a horrible experience. No multiple files / views / buffers, no | >cut-and-paste between windows, no auto auto-indent for the code | | You can, of course, run multiple vi's under any windowing system that | allows it, and use the windowing system's cut and paste if you | prefer it to explicit tmp files (I don't, except when one of the | windows is running something that doesn't know how to use files or | the programs in the different windows don't share a common filesystem). | You can also use an external program to auto-indent or whatever else | you need to do. I may be missing something, but I usually use "ay} to save a paragraph in buffer (?) a, switch files*, and do "ap where I want to put it back. There are at least 26 such buffers available. I also use marks a lot, to move around faster. It seems that these features are not well known. * The only thing I hate about switching files is that vi insists on writing out the current file and reading in the new file in its place. Not always what I want. </Erik> -- Erik Naggum Professional Programmer +47-2-836-863 Naggum Software Electronic Text <ERIK@NAGGUM.NO> 0118 OSLO, NORWAY Computer Communications <enag@ifi.uio.no>
les@chinet.chi.il.us (Leslie Mikesell) (06/05/91)
In article <ENAG.91Jun4002738@gyda.ifi.uio.no> enag@ifi.uio.no (Erik Naggum) writes: >| You can, of course, run multiple vi's under any windowing system that >| allows it, and use the windowing system's cut and paste if you >| prefer it to explicit tmp files >I may be missing something, but I usually use "ay} to save a paragraph >in buffer (?) a, switch files*, and do "ap where I want to put it back. >There are at least 26 such buffers available. I also use marks a lot, >to move around faster. It seems that these features are not well known. I guess my usage may not be typical... I tend to work on configuration files etc. on several different machines at once using either the virtual terminals of a '386 unix console running cu in different sessions or a machine running Microsoft Windows with multiple kermit sessions or a combination of the two. The machines in question may or may not have network links, so I tend not to rely on being able to access the reference file in the same session, but if I know of a common directory on the two machines I usually write the piece I want to a tmp file in one session, jump to the other and read it in. The sessions don't even need to be concurrent. The kermits-under-windows setup is new, so I don't have much experience with the screen cut and paste technique, but it looks good so far. >* The only thing I hate about switching files is that vi insists on >writing out the current file and reading in the new file in its place. >Not always what I want. And the thing I hate about it is that it's not at all obvious where you are going when you switch, unless you remember what you have done so far. If you use explicit tmp files you don't need to know much else about the source of data and it will stay around even if you need to interrupt the sessions. Les Mikesell les@chinet.chi.il.us
lattice@iris.mincom.oz.au (Lattice) (06/06/91)
In article <1991Jun03.151727.9944@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >In article <1991Jun1.021505.4043@trl.oz.au> soh@andromeda.trl.OZ.AU (kam hung soh) writes: >>[...] I decided to dump emacs and use vi exclusively. >>It was a horrible experience. No multiple files / views / buffers, no >>cut-and-paste between windows, no auto auto-indent for the code > >You can, of course, run multiple vi's under any windowing system that >allows it, and use the windowing system's cut and paste if you >prefer it to explicit tmp files (I don't, except when one of the >windows is running something that doesn't know how to use files or >the programs in the different windows don't share a common filesystem). >You can also use an external program to auto-indent or whatever else >you need to do. > I am a recent *convert* to emacs from vi, but I recognise that they are both valuable tools, though emacs is now my editor of choice. With reference to the above I would say two things: 1. There is no need to use an external program for indentation - vi has an autoindent mode, invoked using :set autoindent or :set ai These can be invoked automatically by placing entries in your ~/.exrc file or through the EXINIT env variable. 2. vi does allow you to cut and paste between files, though not as elegantly as emacs - the limitation being more that vi doesn't support windows. For example, "a3Y ; yank 3 lines into buffer 'a' :e otherfile ; call up the file to paste to "ap ; print the contents of buffer 'a' below ; the current cursor position There are many other ways that this can be done, including yanking regions, printing the named buffer before the current line, etc. vi does tend to be fairly orthogonal in this way. mark stavar
les@chinet.chi.il.us (Leslie Mikesell) (06/12/91)
In article <1148@iris.mincom.oz.au> lattice@iris.mincom.oz.au () writes: >I am a recent *convert* to emacs from vi, but I recognise that they are both >valuable tools, though emacs is now my editor of choice. >With reference to the above I would say two things: > 1. There is no need to use an external program for indentation - > vi has an autoindent mode, invoked using > :set autoindent That's fine for typing entirely new code, but what do you do when you add or delete a loop surrounding existing code and want the indentation fixed?. I usually just pipe through cb. Les Mikesell les@chinet.chi.il.us
lattice@iris.mincom.oz.au (Lattice) (06/14/91)
In article <1991Jun11.203851.26928@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >> 1. There is no need to use an external program for indentation - >> vi has an autoindent mode, invoked using >> :set autoindent > >That's fine for typing entirely new code, but what do you do when you >add or delete a loop surrounding existing code and want the indentation >fixed?. I usually just pipe through cb. > In this case I would normally mark the top and bottom of the altered block and use the indent/undent option '>'/'<' respectively, i.e., /* mark the top and bottom of the block as a and b */ :'a, 'b < (or >) I must admit though to having encountered some difficulty with this method when the tabstops value is set to something other than a full tab. Still it can be quite adequate. mark stavar