ian@ukpoit.co.uk (Ian Spare) (11/30/90)
Some of our users/developers have formed a lynch party and came into the
tech support area this morining spoiling for a fight !!! They ( not me ! )
feel that vi is hopeless and would like a better editor ( their words ).
I think the problem is that they find productivity plumments when using
3 editors , namely vi , wordstar and IBM ISPF editors.
I have told them that real programmers work at command line level but they
don't seem to beleive me .
What I think I need is a new editor for them , these are the requirements :
1 . Simple to use.
2 . Look and feel the same as either Wordstar or IBM ISPF editor.
3 . Run on Unix 5.2 & 5.3 on NCR Tower 32/400 , 32/450 and 32/500.
4 . Be fairly efficient , ie not to hungry on system resources.
5 . Run on vt100 / 4970 / vt220 terminals.
6 . Reliability.
I have come across Fenix ( a wordstar look-alike ) but the prefrence is
for IBM ISPF look&feel.
Any clues ???
PS I like vi !! Please don't tell me to use vi , and using emacs will only
confuse them further I think.
--
Ian Spare , iT , Barker Lane , CHESTERFIELD , DERBYS , S40 1DY , GREAT BRITAIN
E-mail : ian@ukpoit.uucp - VOICE : +44 246 214296 - FAX : +44 246 214353
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
iT - The Information Technology Business Of The Post Office
~~~~~~~~~~~~~~~~~~~~~~~ In Tune With Technology ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~tchrist@convex.COM (Tom Christiansen) (12/04/90)
In article <1616@ukpoit.co.uk> ian@ukpoit.co.uk (Ian Spare) writes: >Some of our users/developers have formed a lynch party and came into the >tech support area this morining spoiling for a fight !!! They ( not me ! ) >feel that vi is hopeless and would like a better editor ( their words ). > >I think the problem is that they find productivity plumments when using >3 editors , namely vi , wordstar and IBM ISPF editors. You can lead a horse to water, but you can't make him drink. You cannot make someone learn if they are intent upon ignorance. Let them suffer. Sorry, I've lost sympathy with cretins. I recognize this is harsh, and that a more tactful way of communicating this would have to be found. I've seen lots of secretaries using vi to write complex papers in troff with eqn and tbl. If they can do this, I just can't believe an operator or progammer needs something that hold their hand more. These people are just being lazy. Don't let them make you go through a lot of work just because they don't want to. --tom -- -- Tom Christiasen tchrist@convex.com convex!tchrist "With a kernel dive, all things are possible, but it sure makes it hard to look at yourself in the mirror the next morning." (me)
joshi@cs.uiuc.edu (Anil Joshi) (12/05/90)
tchrist@convex.COM (Tom Christiansen) writes: >In article <1616@ukpoit.co.uk> ian@ukpoit.co.uk (Ian Spare) writes: >> >>I think the problem is that they find productivity plumments when using >>3 editors , namely vi , wordstar and IBM ISPF editors. >You can lead a horse to water, but you can't make him drink. >You cannot make someone learn if they are intent upon ignorance. >Let them suffer. Sorry, I've lost sympathy with cretins. I recognize ^^^^^^^^^^^^^^^^^^^^^^^^^^ I think I lost sympathy with the UNIX fanatics, especially who do not want to even see what some of the better designed editors (read ergonomic editors) have to offer. I think you are totally mistaken. The point of the matter is that vi sucks in sveral ways, where as ISPF is a truly wonderful editor. You do not have some "magic" stuff going on all the time, you do not have to learn regular expressions, join (J) works the way it is supposed to work, defaults for function keys are standardized and more intuitive (and are very easy to change), macros can be written using the ISPF CLIST language (which is a shell on TSO) and is much better than in vi, one can integrate ISPF Screens into the macros much easily than vi, one can replace/find within certain column range (you do not have to count but you can do so if you wish), one does not have to count (a la FORTRAN FORMAT statement) how many times a particular command has to be repeated (though one can do it if one so wishes), line labels are visible, line labels can be upto five characters (unlike the vi's stupid one character labels) and one can exclude certain number of lines which enables one to get a nice overview of the entire program/document/report. No wonder the users are revolting against vi. I am not in any way saying that ISPF Editor is "the" editor, but it has a lot of good features which I would like to have in my UNIX editor. I have not seen these features either in emacs or in vi. Now, there are some features of emacs and vi which I would like to have in ISPF Editor. They are named buffers, passing a marked region through a filter, multiple windows (ISPF provides for two and 90% of the time that was enough for what I was doing - and I was NOT repeat NOT a casual user). These can be done in the editor through macros but I would rather have them as standard features. Also, the regular expression stuff is a bit weak in ISPF. >this is harsh, and that a more tactful way of communicating this would >have to be found. Using vi => frustration => Harshness towards fellow human beings. :-) >I've seen lots of secretaries using vi to write complex papers in troff >with eqn and tbl. You haven't heard what some of the sceretaries here have to say about vi. >operator or progammer needs something that hold their hand more. These >people are just being lazy. Don't let them make you go through a lot >of work just because they don't want to. What is wrong in an editor that holds hands of a casual user who does not need to do very exotic things but provides for the power users too? Is it wrong to have reasonable and sensible defaults, more intuitive function key assignments, more intuitive mnemonics and better user interface? >Tom Christiasen tchrist@convex.com convex!tchrist Anil Joshi (joshi@cs.uiuc.edu) >"With a kernel dive, all things are possible, but it sure makes it hard > to look at yourself in the mirror the next morning." (me) "We are responsible for what we are. 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. We have to know how to act." - Swami Vivekananda, Late Nineteenth Century Indian Philosopher -- "We are responsible for what we are. 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
nhess@gumby.us.oracle.com (Nate Hess) (12/05/90)
In article <109752@convex.convex.com>, tchrist@convex (Tom Christiansen) writes: >Let them suffer. Sorry, I've lost sympathy with cretins. I recognize >this is harsh, and that a more tactful way of communicating this would >have to be found. >I've seen lots of secretaries using vi to write complex papers in troff >with eqn and tbl. If they can do this, I just can't believe an >operator or progammer needs something that hold their hand more. These >people are just being lazy. Don't let them make you go through a lot >of work just because they don't want to. Yeah, you're right. Why the heck would you actually want to increase the productivity of your employees / coworkers? Let 'em struggle with bear skins and knives. Like we had to. Gosh, they *are* lazy cretins for even *thinking* that the tools they have might not be adequate for the job at hand. Why, when we were their ages, we had to edit up-hill both ways... --woodstock -- "What I like is when you're looking and thinking and looking and thinking...and suddenly you wake up." - Hobbes nhess@us.oracle.com or ...!uunet!oracle!nhess or (415) 506-2650
mayoff@cs.utexas.edu (Robert Mayoff) (12/06/90)
In article <joshi.660338789@m.cs.uiuc.edu> 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? Let me say right up front that I have used (in this order): 1. Personal Editor II for the IBM PC 2. Turbo Pascal (and, later, Turbo C) Editor 3. vi 4. XEDIT on VM/CMS 5. emacs 6. ISPF on VM/CMS I know (or once knew) how to write macros for PE2, vi, and XEDIT (in REXX). After having used all of these, I'd say that the best editor for people who are non-computer-oriented is PE2 for the PC, and the best for computer people is either vi or emacs. Let me explain why. PE2 has *excellent* response time, supports multiple files and windows, and has a *very* easy-to-use macro capability. Commands are generally bound to the function keys and to ALT-keystokes. The macro capability (last time I checked) doesn't offer any control constructs, but it's simple to use because every editor function has a long mnemonic name and a short two-character name, and any key can be bound to a list of functions, either spelled out or abbreviated. The problem that "power users" might have (or at least, the problem I have with it) is that most major functions, such as cursor motion and saving/searching/etc. are bound to the arrow keys and to function keys. I type 70 wpm or more, so it slows me down to have to move my hands off the home row. The Turbo Pascal (and other Borland-products) editor is basically WordStar, and doesn't have much of a macro capability, as I recall. I never liked it very much, though I don't remember why now (it's been a long time). 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 eliminates the problem of taking my hands off the home row. I freely admit that a modal editor can be difficult to use, but I personally have never had a problem with it. vi offers a limited macro capability in a similar vein to PE2, except that the macros are defined by actual keystrokes, not function-names. However, since vi is built atop ex, the user has access to all of the ex functionality. True, ex is getting to be quite obscure since most people never touch a teletype anymore (I said *most people*, no flames please). However, if you're willing to spend the time to learn a few of its commands, or have a master to teach you, then the power to be gained is very worthwhile. In addition, vi offers regular-expression matching, which I've only found in one other editor, emacs. I use regular-expression matching quite often (daily, probably). Another feature about vi is that the user can pipe parts of a file through a filter. Most people never do this, and may not even know about it, but I've learned to do some pretty fancy stuff using sort, colrm, cut, paste, fmt, etc. emacs is another good editor. There's a lot of religious debate in UNIX circles about which is better, vi or emacs. I've posted before, admitting that emacs is a better editor and explaining why; but I also explained why I still prefer vi. Simply: I don't like lisp, I don't like running under an interpreted (read: slow) environment, and emacs (GNU Emacs, that is) is both. However, for those that can stand lisp, and are willing to put up with a slightly (but only slightly) slower editor, with a virtual unlimited macro capability, emacs may be the way to go. The ISPF editor is a very old editor, but still useful. However, given the opportunity, I'd still use XEDIT. I got the feeling this summer when I worked at IBM that there's an ISPF vs. XEDIT religious debate in IBM mainframe circles along the lines of the vi vs. emacs debate in UNIX circles. I met people over the summer who were amazingly proficient at ISPF, and I was continually impressed with the little tricks they did. However, one major problem I have ISPF is that it *always* shows sequence numbers. There's no way to turn them off. Now, sequence numbers are fine for programming, but when I read mail that's been written in 80 columns, 72 columns just aren't enough. Also, although ISPF provides a macro facility, I could never figure out how to redefine keys to my heart's content. Finally, there's the fact that it runs on 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. 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 - it's much more flexible than ISPF, and offers (as far as I can tell) most of the features of ISPF. Flame-shield activated. -- /_ rob <mayoff@cs.utexas.edu> /_ Fun things to do with UNIX (#72 in a series): / cat /dev/zero > /dev/null
peter@ficc.ferranti.com (Peter da Silva) (12/06/90)
You want a better editor than VI or Emacs to see widespread use on UNIX? Write one, and give it away. It wouldn't have to be big or sophisticated: if you published the source on the net people *will* upgrade it. It does have to be easy to build and install, and start out moderately small. It's hard for a commercial program to compete with free. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com
joshi@cs.uiuc.edu (Anil Joshi) (12/06/90)
mayoff@cs.utexas.edu (Robert Mayoff) writes: >In article <joshi.660338789@m.cs.uiuc.edu> 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? >Let me say right up front that I have used (in this order): >1. Personal Editor II for the IBM PC >2. Turbo Pascal (and, later, Turbo C) Editor >3. vi >4. XEDIT on VM/CMS >5. emacs >6. ISPF on VM/CMS Have you used ISPF on MVS? >non-computer-oriented is PE2 for the PC, and the best for computer people is >either vi or emacs. Let me explain why. ^^^^^^^^^^^^^^^^^^^ I don't agree with you on this. You have not answered the questions I asked in my original note re. some capabilities. >PE2 has *excellent* response time, supports multiple files and windows, and has I can't say much on this topic, because I have not used PE2. >doesn't have much of a macro capability, as I recall. I never liked it very >much, though I don't remember why now (it's been a long time). Neither did I. Reason is simply that they are not programmable. >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?) >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? >that a modal editor can be difficult to use, but I personally have never had a >problem with it. vi offers a limited macro capability in a similar vein to >PE2, except that the macros are defined by actual keystrokes, not >function-names. > However, since vi is built atop ex, the user has access to all >of the ex functionality. True, ex is getting to be quite obscure since most 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? 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? 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. >people never touch a teletype anymore (I said *most people*, no flames please). >However, if you're willing to spend the time to learn a few of its commands, or >have a master to teach you, then the power to be gained is very worthwhile. In >addition, vi offers regular-expression matching, which I've only found in one 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. >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. >prefer vi. Simply: I don't like lisp, I don't like running under an >interpreted (read: slow) environment, and emacs (GNU Emacs, that is) is both. ^^^^^^^^^^ I agree with you entirely. An editor should be the fastest piece of software because that is the primary link between a programmer and the computer. I have absolutely no sympathy for people who say that we have these 1001 features but my editor runs 100 times slow. >The ISPF editor is a very old editor, but still useful. However, given the May be you used the older version. 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? 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. 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.). >opportunity, I'd still use XEDIT. I got the feeling this summer when I worked >at IBM that there's an ISPF vs. XEDIT religious debate in IBM mainframe circles >along the lines of the vi vs. emacs debate in UNIX circles. I met people over 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 don't know why you got the impression that I am rooting for any one of these editors. 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". >the summer who were amazingly proficient at ISPF, and I was continually >impressed with the little tricks they did. However, one major problem I have >ISPF is that it *always* shows sequence numbers. There's no way to turn them ^^^^^^^^^^^^^^^^^^^^^^^ 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. >off. Now, sequence numbers are fine for programming, but when I read mail >that's been written in 80 columns, 72 columns just aren't enough. Also, 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). >although ISPF provides a macro facility, I could never figure out how to >redefine keys to my heart's content. Finally, there's the fact that it runs on There is a problem. Keys cannot be redefined. But it is not such a big deal. >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? >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. >Flame-shield activated. >-- >/_ rob <mayoff@cs.utexas.edu> > /_ Fun things to do with UNIX (#72 in a series): Anil Joshi (flame away all you want. I am busy this week, but will scorch you back in January). -- "We are responsible for what we are. 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
rouben@math13.math.umbc.edu (Rouben Rostamian) (12/06/90)
In article <joshi.660440350@m.cs.uiuc.edu> joshi@cs.uiuc.edu (Anil Joshi) writes: >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. Yes. :source filename >>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. To pipe a part of a file through a filter you should first know how to refer to that part of the file. There are zillions of ways of doing this depending on the particular instance and on your experience and taste. Here are a couple examples: :'a,.w !spell Spell-check from "mark a" to "here" !}fmt -72 Run "here" to the end of paragraph through fmt(1) where "here" refers to the location of cursur. In the second example the output of the fmt filter replaces the original text. In the first instance the output of spell(1) is shown at the bottom of the screen and then disappears after a carriage return. -- Rouben Rostamian Telephone: (301) 455-2458 Department of Mathematics and Statistics e-mail: University of Maryland Baltimore County bitnet: rostamian@umbc Baltimore, MD 21228, U.S.A. internet: rostamian@umbc3.umbc.edu
ewoods@hemel.bull.co.uk (Eoin Woods) (12/06/90)
joshi@cs.uiuc.edu (Anil Joshi) writes: ^ . . Deleted Stuff . v >May be you used the older version. 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. Agreed! >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? Yes! >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. 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.). I think that this is a little unfair - GNU Emacs is produced by the Free Software Foundation (FSF) - No there are no guarantees, but then as it is distributed free it really isn't possible to give any for economic reasons. Yes, I do believe that Richard Stallman et al DO care about their end user, but it is worth remembering that the end user intended for Emacs (and indeed Vi) is a PROGRAMMER - not a typist. FSF do put 'everything they have got' into the GNU tools that they produce, because that is basically all that they do - The low number of problems reported over USENET seem imply that FSF do have a working quality assurance policy (although I personally doubt whether it is as formal as all that). Just a few thoughts! Eoin. PS - As Peter Da Silva said in a few postings back - Why not write a PD editor that is focused towards typists/end users rather than programmers. FSF are you listening?? :-) -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~ Eoin Woods, Software Development Group, Bull HN Information Systems, ~ ~ Maxted Road, Hemel Hempstead, Herts HP2 7DZ ~ ~ Tel : +44 442 232222 x4823 ~ ~ Fax : +44 442 234084 ~ ~ < Eoin.Woods@hemel.bull.co.uk > ~ ~ < When do we start news group comp.os.emacs ? :-) > ~
birger@eik.ii.uib.no (Birger A. Wathne) (12/06/90)
There is already one good free editor out there. Crisp is a fairly good brief-clone. It's got full macro-facilities, key rebinding, windowing, etc.
I have used it for some time, and my only complaint is that installing it for a few different terminal types takes a lot of time. It needs separate info-files for each keyboard and terminal type.
It would also be nice if the newer macro language for brief was implemented. In the version i have, only the old-style macro language exists.
And finally. X-support would be really nice. At lest basic mouse support. Anyone done it?
--
____ ____ ____ ____ ____ birger@ii.uib.no
/ / / / / / / / / /
/ / / / / / / / / / Birger A. Wathne
/--- / /--- / __ /--- /--- Blekenberg 14
/ / / / / / / / / / N-5037 SOLHEIMSVIK
/____/ / / / /____/ /____ / / tlf: +47-5-20 00 62simon@castle.ed.ac.uk (Simon Brown) (12/07/90)
In article <1616@ukpoit.co.uk> ian@ukpoit.co.uk (Ian Spare) writes: > >Some of our users/developers have formed a lynch party and came into the >tech support area this morining spoiling for a fight !!! They ( not me ! ) >feel that vi is hopeless and would like a better editor ( their words ). > >I think the problem is that they find productivity plumments when using >3 editors , namely vi , wordstar and IBM ISPF editors. silly remark #1: yeah, it's probably best to try to stick to one at a time. maybe two... > >What I think I need is a new editor for them , these are the requirements : > 2 . Look and feel the same as either Wordstar or IBM ISPF editor. silly remark #2: but didn't they just say that these are the other ones that make their productivity plummet? maybe they meant "look and feel *not* the same as ..." - a rather more likely request, i can't help thinking :-) --Simon ------------------------------------------------------------------------------- Simon Brown simon@meiko.co.uk Meiko Scientific Ltd. simon@uk.ac.ed (Edinburgh Office, Edinburgh Parallel Computing Centre) #include <stddisclaimer.h>
mayoff@cs.utexas.edu (Robert Mayoff) (12/07/90)
In article <joshi.660440350@m.cs.uiuc.edu> joshi@cs.uiuc.edu (Anil Joshi) writes: > >mayoff@cs.utexas.edu (Robert Mayoff) writes: > >>In article <joshi.660338789@m.cs.uiuc.edu> 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 <mayoff@cs.utexas.edu> /_ Fun things to do with UNIX (#72 in a series): / cat /dev/zero > /dev/null
joshi@cs.uiuc.edu (Anil Joshi) (12/07/90)
simon@castle.ed.ac.uk (Simon Brown) writes: >silly remark #1: > yeah, it's probably best to try to stick to one at a time. maybe two... Why? If there are a lots of choices, let everybody use what they want and are comfortable with. >> >>What I think I need is a new editor for them , these are the requirements : >> 2 . Look and feel the same as either Wordstar or IBM ISPF editor. >silly remark #2: > but didn't they just say that these are the other ones that make their > productivity plummet? maybe they meant "look and feel *not* the same as > ..." - a rather more likely request, i can't help thinking :-) This is really unfair. It is because of the users all of us programmers have our jobs. If the users want ISPF Editor's look and feel then that's what they should get. If you like UNIX and you want the users to use it then give them what they like - don't give them what you like. If you do that most probably that would be the last thing you would be giving them. I don't know how it works in other companies but the places I have worked, user has to be satisfied or else... If there was a lynch party, then there must be some truth in what they are saying. How can you judge their productivity? They are the ones who judged it and finally the verdict is out - they prefer ISPF to vi. Now however much you scream and shout, for what they want to do, they find that more productive. By screaming or becoming combative, you can't change that. Is it that difficult to change vi to emulate ISPF? If so, may be emacs can do the job (may be a tad slowly). Anil Joshi -- "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. how to act." - Vivekananda, Late Nineteenth Century Indian Philosopher
bob@ns.UUCP (Robert J. Mathias) (12/07/90)
>I've seen lots of secretaries using vi to write complex papers in troff >with eqn and tbl. If they can do this, I just can't believe an >operator or progammer needs something that hold their hand more. These >people are just being lazy. Don't let them make you go through a lot >of work just because they don't want to. > Unlike secretaries, programmers (those that don't come from Unix) have been exposed to other editors. Once a programmer with an open-mind has used a screen-based editor, they have a hard time accepting an editor like vi (a line-oriented editor with a screen interface grafted upon it). So why call them lazy when they only want better tools? -- Robert J. Mathias, Jr uucp: ...!uunet!ccicpg!uis-oc!ns.UUCP!bob Unisys Corporation voice: (714) 727-0323 A and V Series Systems Engineering fax: (714) 727-0350 Irvine, California
peter@ficc.ferranti.com (Peter da Silva) (12/08/90)
[ I asked... if you want a good free editor then write one ] In article <1990Dec6.133414.28539@eik.ii.uib.no> birger@eik.ii.uib.no (Birger A. Wathne) suggested CRISP: > I have used it for some time, and my only complaint is that > installing it for a few different terminal types takes a lot of > time. It needs separate info-files for each keyboard and terminal > type. Exactly. One of the things that a UNIX editor needs is that it be easy to install. None of this customising for terminal types business (what's termcap/terminfo for then?) or having to pre-compile all your macros. Plus, Brief really wants a meta-key to work right, even more so than Emacs. And it really needs a memory mapped screen. This shows through in Crisp. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com
jmm@lsuc.on.ca (John Macdonald) (12/08/90)
In article <4629@umbc3.UMBC.EDU> rouben@math13.math.umbc.edu.UUCP (Rouben Rostamian) writes: >In article <joshi.660440350@m.cs.uiuc.edu> joshi@cs.uiuc.edu (Anil Joshi) writes: >>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. Actually, yes, it is possible. I have not had occassion to have done it, but a few (very messy) macros could do the following (not in proper format, just an outline of how it could be done) <start-args> remember current position start collecting text for next arg <next-arg> stop collecting text and put it into the next buffer start collecting text for next arg <finish-args> stop collecting text and put it into the next buffer go back to original position (I have left out a lot of detail - in particular, keeping track of the "next buffer" would be done by having <start-args> initialize a control buffer to the list of buffer names to be used [e.g. "abcdef"], and putting text into the next buffer requires getting the control buffer, deleting the first character and returning the rest, building a command [using the deleted next buffer character] that will delete the collected text into the buffer.) Now it is just a matter of writing macros that expect their arguments in the proper named buffers. This requires dedicating a number of named buffers and named marks to this operation. >>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. > >Yes. >:source filename If you do this a lot, it could be useful to define a macro in your .exrc that generates ":source /usr/home/fred/lib/vi.macros/" so that you can have a library of sourcable vi definition files accessible wherever you are. If you only have a few of these, you could set up a sep1M~varate macro to fully invoke each one, complete with the terminating newline.
dattier@ddsw1.MCS.COM (David W. Tamkin) (12/08/90)
joshi@cs.uiuc.edu (Anil Joshi) wrote in <joshi.660440350@m.cs.uiuc.edu>: | 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? Of course you can. Use the :so (for "source") command. | 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. You can pass a contiguous range of whole lines through a filter with :first,last !filter; first and last do not have to be numbers but can be any legitimate way for to designate a line in an ex command. If the area to be filtered begins or ends in the middle of a line, you can break the line, filter the appropriate section, and then rejoin the parts. David Tamkin Box 7002 Des Plaines IL 60018-7002 708 518 6769 312 693 0591 MCI Mail: 426-1818 GEnie: D.W.TAMKIN CIS: 73720,1570 dattier@ddsw1.mcs.com
john@newave.UUCP (John A. Weeks III) (12/08/90)
In article <1616@ukpoit.co.uk> ian@ukpoit.co.uk (Ian Spare) writes: > Some of our users/developers have formed a lynch party and came into the > tech support area this morining spoiling for a fight !!! They ( not me ! ) > feel that vi is hopeless and would like a better editor ( their words ). I have heard that brief and wordstar are far superior to "vi". After all, vi is not even DOS compatible. I suggest that do the following: cp /bin/vi /bin/wrdstr Then open the file "vi.doc" (or what ever your online editor help file is) and run the following vi command ":%s/vi/wrdstr/g". Finally, mail a message to everyone telling them that the new and improved wrdstr editor has been installed on the system. This should fix any complaints about vi ;-). Then go back to doing something productive with your limited time (or go out for doughnuts). -john- -- =============================================================================== John A. Weeks III (612) 942-6969 john@newave.mn.org NeWave Communications ...uunet!rosevax!tcnet!wd0gol!newave!john ===============================================================================
jmaynard@thesis1.hsch.utexas.edu (Jay Maynard) (12/12/90)
In article <joshi.660533000@m.cs.uiuc.edu> joshi@cs.uiuc.edu (Anil Joshi) writes: >Is it that difficult to change vi to emulate ISPF? If so, may be >emacs can do the job (may be a tad slowly). I seriously doubt that either vi or emacs could be made to emulate the ISPF editor, much less perform the other functions that ISPF does. TSO programmers spend more of their time in ISPF than emacs users spend inside emacs. It has an astonishingly rich set of functions, and doing them all would be quite a task. Even the editor is markedly different from the typical Unix screen- oriented text editor; it's a cross between a screen editor and a line editor, and some things are more easily done as line commands (entered in fields at the beginning of each line) than as functions in the text portion of each screen. The model of interaction with ISPF was designed around the capabilities of the 3270-series CRTs instead of character-at-a-time async terminals. The original poster will be better advised to use dte, a WordStar-like editor that appeared recently in comp.binaries.ibm.pc - but with Unix source as well. -- Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can jmaynard@thesis1.hsch.utexas.edu | adequately be explained by stupidity. "...flames are a specific art form of Usenet..." -- Gregory C. Woodbury
mercer@npdiss1.StPaul.NCR.COM (Dan Mercer) (12/12/90)
In article <550@newave.UUCP> john@newave.mn.org (John A. Weeks III) writes: :In article <1616@ukpoit.co.uk> ian@ukpoit.co.uk (Ian Spare) writes: :> Some of our users/developers have formed a lynch party and came into the :> tech support area this morining spoiling for a fight !!! They ( not me ! ) :> feel that vi is hopeless and would like a better editor ( their words ). : :I have heard that brief and wordstar are far superior to "vi". After all, :vi is not even DOS compatible. I suggest that do the following: : : cp /bin/vi /bin/wrdstr : :Then open the file "vi.doc" (or what ever your online editor help file is) :and run the following vi command ":%s/vi/wrdstr/g". Finally, mail a message :to everyone telling them that the new and improved wrdstr editor has been :installed on the system. : :This should fix any complaints about vi ;-). Then go back to doing :something productive with your limited time (or go out for doughnuts). : :-john- : This, of course, will not work, for wrdstr will actually come up in ex mode. Observe the ls -il of /usr/bin: 666 -rwxr-xr-x 5 bin 147528 Jan 6 1989 edit 666 -rwxr-xr-x 5 bin 147528 Jan 6 1989 ex 666 -rwxr-xr-x 5 bin 147528 Jan 6 1989 vedit 666 -rwxr-xr-x 5 bin 147528 Jan 6 1989 vi 666 -rwxr-xr-x 5 bin 147528 Jan 6 1989 view ex examines argv[1] to determine which mode to come up in. The default [non-match] is the original, ex. As for the original question, when I was first introduced to UNIX 5 or 6 years ago, after years of editing on TSO/MVS, I too was daunted by vi. Our entire group went to management after first getting our UNIX system and begged for a 'better' (i.e. different) editor. While we searched for a different editor, we started grudgingly to learn vi. After a week, we were still complaining. After two weeks, we had discovered some of the interesting things that can be done and we cancelled looking for another editor. After three months, we had totally scrapped the custom built user interface we were designing in favor of an interface built entirely around vi (drop down menus, calls to other programs, all communicating across FIFOS). We did our original UNIX programming on an Amdahl UTS system with its 'ned' editor that allowed for the importation of skeletons. I liked that feature so well that I built my own version linked across an input and out FIFO. A function key causes the current line to be written to the input FIFO and then reads the output FIFO. vi blocks on the read and the background processes unblocks on its read of the input FIFO, gets the current line, pattern matches against a database and if it finds no hits, pattern matches against the lintlibs. It formulates the response, either a skeleton or the lintlib line and writes that to the output FIFO. In the blink of an eye te patterns in my file ready to edit. The other thing I loved about vi was its interaction with the shell. Building a quicky awk program in the file then feeding it to the shell is great for building arrays (character translation, CRC checking, etc). Of course, I'm a hacker. There were four people in our group - two hackers and two plodders. The plodders didn't even know how to to global substitutions and refused to learn. Used to irritate the hell out of me watching them plow through a file and change everything by hand. Of course, they'd never really learned to use the ISPF editor, either. The code they wrote was pretty bad, too. Vi is really a programmer's editor. The better the programmer, the better one likes vi. Actually, the average person needs only the most rudimentary editor to do his/her work. This may explain why so much programming is so average. We did find an SPF style editor for UNIX - try looking through 5 year old copies of UNIX World. I've looked through recent copies, but no luck. They may be out of business. -- Dan Mercer NCR Network Products Division - Network Integration Services Reply-To: mercer@npdiss1.StPaul.NCR.COM (Dan Mercer) "MAN - the only one word oxymoron in the English Language"
joshi@cs.uiuc.edu (Anil Joshi) (12/12/90)
jmaynard@thesis1.hsch.utexas.edu (Jay Maynard) writes: >I seriously doubt that either vi or emacs could be made to emulate the ISPF >editor, much less perform the other functions that ISPF does. TSO programmers >spend more of their time in ISPF than emacs users spend inside emacs. It has That exactly was my point. But I didn't say it this well. The system tools all put together give a more programmer/user friendly and easthetic results on IBM Mainframes than on the UNIX systems. The only UNIX clone that even came to close to the functionality of ISPF is VOS on Stratus. If somebody says that all these things are fitting in together just by conincidence, I won't believe them (think about with what probability that could happen). It is not just serendipity - it is a lot of planning and research into how they can be integrated well with each other. Only in the UNIX world, I see this disturbing trend of haphazard development without some common goal in sight. With cute names like awk, GNU or some cute feature like "How to put Latex trademark into my document?" which have no wide usage (some of the statements in the Latex Manual irritate me to the limit) or would require tremendous amount of programming knowledge (or regular expressions or whatever) or both. You may ask why I am talking about UNIX in this NewsGroup. It is because of the following reasons. 1. As I already said before, editor, according to my gut feeling, is the most used tool on a computer. 2. vi and emacs both follow in the foot steps of general UNIX philosophy of software development - "To heck with the user -- We are buddy-buddy with the power user/programmer. I'll help programmers write more and more utilities, more and more system software stuff, I'll put in this cute feature in here that is going to give the programmers so and so". What about the end-users? 3. Please (this is an impassioned plea) do not make the mistake of underestimating/sneering at the users. Please listen to them. If they don't like something there must be a reason for it. If they wanted vi to look like ISPF Editor (or more globally UNIX to look like MVS/TSO/ISPF) then there must be some truth in what they are saying. If there are only UNIX users (as the case very welll might be wherever Tom is working), then they would not have had a chance to see som of the better things that are there in the market. The places where they do see (I forget the name of the person who posted the original "vi alternative required") more than one, the choice definitely was not the UNIX editor. You as a programmer most probably would be able to bully them around and say that "Look! You either use this or else I am not going to help you anymore." Can't we (collective) have a more productive solution than this "tough luck. You can't do this" attitude? >an astonishingly rich set of functions, and doing them all would be quite a >task. Even the editor is markedly different from the typical Unix screen- >oriented text editor; it's a cross between a screen editor and a line editor, >and some things are more easily done as line commands (entered in fields at >the beginning of each line) than as functions in the text portion of each >screen. The model of interaction with ISPF was designed around the >capabilities of the 3270-series CRTs instead of character-at-a-time async >terminals. >The original poster will be better advised to use dte, a WordStar-like editor >that appeared recently in comp.binaries.ibm.pc - but with Unix source as well. That is another problem - all these WYSIWYG stuff. They are not quite WYSIWYG and at the same time are quite cumbersome to use. >-- >Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can >jmaynard@thesis1.hsch.utexas.edu | adequately be explained by stupidity. > "...flames are a specific art form of Usenet..." -- Gregory C. Woodbury Anil Joshi (I am not a spokesperson for any of the hardware vendors. These opinions are mine and mine only. I am proud to have them.) -- "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. how to act." - Vivekananda, Late Nineteenth Century Indian Philosopher
shore@mtxinu.COM (Melinda Shore) (12/12/90)
[]
I think you're missing the point. Every system has its own idiom, and
those idioms should be respected wherever possible. Failure to do so
results in awkward, inappropriate user interfaces, redundant functionality,
and a haphazard environment. Just because ISPF works marvellously well
in an MVS environment doesn't mean that it's an appropriate editor or
toolset for other operating systems. Similarly, just because you aren't
yet familiar with the idioms of some other operating system, don't assume
it's incorrect because it doesn't respond when you use the conventions
you know from the one you grew up with. The old adage "sloppy workers
blame their tools" is probably an overstatement, but it really does
seem to me to be unreasonable to say "{vi,Unix,whatever} can't do x"
when you really don't know that for a fact.
Me, I use emacs for some things, vi for other things, ed for yet other
things, and dd for those special moments when all I have is a kernel,
a shell, fsck, newfs, and dd. I have consistently been impressed with
the amount of real work I can get done quickly, efficiently, and with
a minimum of fuss (*and* without running IEFBR14) by learning how to
use the tools in the spirit and idiom in which they were designed.
--
Hardware brevis, software longa
Melinda Shore shore@mtxinu.com
mt Xinu ..!uunet!mtxinu.com!shoreewoods@hemel.bull.co.uk (Eoin Woods) (12/12/90)
joshi@cs.uiuc.edu (Anil Joshi) writes: >2. vi and emacs both follow in the foot steps of general UNIX >philosophy of software development - "To heck with the user -- >We are buddy-buddy with the power user/programmer. I'll help >programmers write more and more utilities, more and more system >software stuff, I'll put in this cute feature in here that is going >to give the programmers so and so". What about the end-users? Maybe so, but I've never met a *real* end-user (who wasn't an ex-programmer, DBA ...) who liked ISPF's editor either!! Eoin. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~ Eoin Woods, Software Development Group, Bull HN Information Systems, ~ ~ Maxted Road, Hemel Hempstead, Herts HP2 7DZ ~ ~ Tel : +44 442 232222 x4823 ~ ~ Fax : +44 442 234084 ~ ~ < Eoin.Woods@hemel.bull.co.uk > ~ ~ < When do we start news group comp.os.emacs ? :-) > ~
gray@s5000.RSVL.UNISYS.COM (Bill Gray x2128) (12/13/90)
May I ask if this newsgroup makes a distinction between "editors" and "word processors?" It seems like one of the original poster's needs is not for an editor at all, but for a PCish word processor. This is not an unreasonable request. And I have seen word processors on Unix systems. I used one on a Motorola/Phase 4 and it seems like there was one on an Intel system I used. Surely there are others out there, and if not, I bet there's a good market opportunity for someone. I use vi and it serves me well. But there are clearly users and applications for which vi or emacs are poor choices. However, the original poster needs to remember that users tend to get passionate about their first love among editors/wp software. No amount of reason can get many cyberphobics to learn and come to respect something designed with different goals than their One True Editor/WP. If you are not careful in what you promise and let users believe is attainable, you have a real tar baby. Bill -- : gray@rsvl.unisys.com : "There are four kinds of : : : homicide: felonious, excusable, : : Unisys has enough problems without being : justifiable, and praiseworthy." : : blamed for my personal opinions. : --Ambrose Bierce :
steveha@microsoft.UUCP (Steve Hastings) (12/13/90)
In article <joshi.660440350@m.cs.uiuc.edu> joshi@cs.uiuc.edu (Anil Joshi) writes: > >mayoff@cs.utexas.edu (Robert Mayoff) writes: >>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 > ^^^^^^^^^^^^^^^ I love the speed of vi, and as a touch-typist I love the keyboard layout. >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?) Other editors exist, but vi/emacs are the most common. You might look into Microsoft Word for XENIX, a product of the Santa Cruz Operation (SCO). It wants a 386 UNIX (preferably SCO UNIX 386, of course). >>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? I have met typist/secretary types who like vi, but they are few. I suspect it is because most people don't prefer modal editors. The lack of training may have something to do with it, too, and the secretaries probably want good manuals. Another problem is that vi is not a word processor. It is a text editor. While it is more efficient in terms of machine resources to split the two functions, like vi and troff, human resources are much more important than machine resources. vi is *not* a good solution for someone who needs a word processor -- for example, a secretary. >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? There are a number of such manuals for vi. I prefer the "research papers" that I already have, so I can't give you a title or author, but I saw a very good book that explained vi in great detail, including how to use common UNIX tools with vi. Check bookstores, or this newsgroup. >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? You can do some tricky things with yanking text into buffers to build a command, and then using the @ command to run the command in the buffer. But I never do that. I don't have any macros with parameters, and so far I don't miss them. >can I run some other .exrc like file from inside the editor? :source filename<enter> >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. ^foo^bar will change a teeny-weeny little character in the middle of the previous command quite conveniently. Just make sure that you have enough context in front of the character that it is recognized. Example: % vi bif_long_hairy_filename # Oops % ^if^ig # Fix it vi big_long_hairy_filename # csh echoes and runs the fixed command > 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. I do not understand this comment. The C Shell history mechanism was designed for paper teletypes, and is therefore line-editor oriented. The Korn shell has what you want: it uses either Emacs or vi emulation to edit old commands. But this has little to do with vi. Your complaint about regular expressions does not pertain to vi, though. vi offers about six ways to do anything, and does not require any use of regular expressions. Try this some time: :g/foo/o<enter> This will find every line with "foo" in it and run vi in open mode on each such line. (You hit 'Q' when done with each line, to see the next one.) Then you can use standard vi commands to fix up the line any way you like. You can also just do this: /foo<enter>, then fix up the line as you want it, then hit 'n' for the next "foo" in the file. By the way, if the edit is very simple, you can often just hit the '.' key to repeat it. ('.' repeats the last single command in vi.) If you or your users don't like regular expressions, :set nomagic<enter> >>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. If you want to pipe part of a file through the filter, and replace that part of the file with the result, use the '!' command in vi mode. Example: sort lines. The '!' command works like the 'd' command in that once you type it, it waits for you to give it any movement command to tell it how much to work on, and as a special case "!!" works on a whole line. So: !Gsort<enter> # pipe the rest of the file through sort 20!!cat -n<enter> # number the next 20 lines (starting at 1) mb # mark a line with the letter 'b' # go to some other line with any movement commands !'bsort<enter> # sort all lines from the marked one to the current one !}fmt<enter> # pipe the next paragraph through fmt (reformat paragraph) # note that vi has naive ideas about what a paragraph is If you want to pipe a copy of some lines through a filter and see the result, you use the "w !" command, like this: :w !spell<enter> # check spelling on the whole file :'b,'ew !spell<enter> # check spelling on the lines from mark b to mark e :2,36w !spell<enter> # check spelling on lines from 2 to 26 If you want to read in the output of a command, do it like this: :r !ls<enter> # put a directory listing in the editing buffer >I agree with you entirely. An editor should be the fastest piece of >software because that is the primary link between a programmer and the >computer. This is why no other editor has replaced vi for me. >Am I wrong in assuming that >they have been basically developed by some grad. students? 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. 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.). This is a spurious argument. vi was written by a graduate student, true, and the results reflect his ideas about what is a good editor. His ideas mesh well with mine, so I like the result. On the other hand, IBM Display Write is one of the worst word processors available, even though is is sold for real $s and there were continual improvements made to it. (I read in PC Week that IBM is scrapping Display Write and that the next version of Display Write will be a XYWrite OEM version.) The people who like Emacs are the ones who like to be able to radically rearrange the user interface, and use their editor to read their mail, run their shell commands, and so on. There are many, many features available in Emacs. I prefer a lean, mean editor like vi, but the people who like Emacs aren't stupid and aren't just using it because it is free. >There is a problem. Keys cannot be redefined. But it is not such a big >deal. I consider a lack of macros to be a grave deficiency in an editor. Most of my macros are dirt simple, but they save so much typing I don't want to live without them. >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. I'm not sure I buy this. You can have a stream-oriented terminal with buffering, and it is possible to have an I/O system that handles the keystrokes without interrupting the main CPU. Have you ever heard of I/O processors? > Ever wonder why UNIX editors are so slow? vi isn't slow unless UNIX is slow. There are some inefficiencies when you have to send and receive escape sequences, but these are generic to any terminal-based software. vi on the console is *really* fast. >Yes I am screwed. I am stuck with vi and/or emacs and dumb esprit >terminal which shows only 24 lines. Sounds to me like you would want to get Emacs. Anything Emacs does that you don't like, you can fix by rewriting the macros. You won't get blazing speed, though, unless you use vi. And if you use vi a while you might even get to like it. -- Steve "I don't speak for Microsoft" Hastings ===^=== ::::: uunet!microsoft!steveha steveha@microsoft.uucp ` \\==|
mayoff@cs.utexas.edu (Robert Mayoff) (12/14/90)
In article <33@ns.UUCP> bob@ns.UUCP (Robert J. Mathias) writes: >Once a programmer with an open-mind has used >a screen-based editor, they have a hard time accepting an editor like vi >(a line-oriented editor with a screen interface grafted upon it). Well, I have used a variety of editors and word processors, on PCs, Macs, Suns, IBM 370s, and Apple //s. I prefer vi over any other text processor, and a vi/troff or vi/latex combination over any word-processor that I have used. I like vi for its blazing speed and its keyboard layout (hey, I *like* modes!), and I like the flexibility that troff or latex offer. >So why >call them lazy when they only want better tools? I agree, they're not lazy; disliking vi is no crime. However, better tools is simply a state of mind. Or lack thereof, in the case of Emacs. (that's a joke! :-) -- /_ rob <mayoff@cs.utexas.edu> /_ Fun things to do with UNIX (#2 in a series): / echo "rsh `hostname` -n source eat.cpu &" > eat.cpu; source eat.cpu
grahj@gagme.chi.il.us (jim graham) (12/16/90)
>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.). Yeah, I've heard this argument before --- "if you don't have to spend a fortune on it, it can't possibly be a worthwhile thing...." Well, I guess things like Elm, rn, nntp, TeX, X11, etc. are all worthless. :-) I mean, these are all "free-bee" products, as you put it. So, I guess these are all supposed to be worthless? The fact is, vi and emacs are popular because people like them. I happen to love vi, and hate emacs. I have several friends who hate vi and love emacs. I also know people who love xedit (the ibm xedit...not the one that comes with X11). Everyone has their own tastes in editors and user-interfaces. I had this conversation a while back with one of the xedit people I know. I was showing him a dos editor called Qedit (with qedwp config files), which is one of the more popular dos editors. It's a very simple editor to use...you just type away. it has lots of macros (defined in the qedwp config files), etc., and any of these can be re-defined easily. it allows you to use split-screen to edit multiple files or multiple areas of the same file. The response I got was clear --- "ok, so it's easy to use...what good is that? why should I care if it saves me 10 keystrokes per operation? you're just too lazy to do the extra work, so you think this is a better editor...." This was from a *real end user*. Oh well, enough....my phone bill is high enough as it is.... Jim Graham Comments, etc., to grahj@gagme.chi.il.us Flames to /dev/null (one way or another)
ewoods@hemel.bull.co.uk (Eoin Woods) (12/17/90)
mercer@npdiss1.StPaul.NCR.COM (Dan Mercer) writes: >Vi is really a programmer's editor. The better the programmer, the >better one likes vi. Now that's what I call a contentious point!! :-) Eoin. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~ Eoin Woods, Software Development Group, Bull HN Information Systems, ~ ~ Maxted Road, Hemel Hempstead, Herts HP2 7DZ ~ ~ Tel : +44 442 232222 x4823 ~ ~ Fax : +44 442 234084 ~ ~ < Eoin.Woods@hemel.bull.co.uk > ~ ~ < When do we start news group comp.os.emacs ? :-) > ~
em@dce.ie (Eamonn McManus) (12/20/90)
In comp.unix questions tchrist@convex.COM (Tom Christiansen) writes: >:Has anyone got a set of 'map!' commands that implement arrow keys in >:'vi' Input mode? > >Yes, I've mailed Richard a uuencoded copy. I posted it very recently in >comp.editors, so don't think I should post it again here. As I (apparently) never tire of pointing out, it's not possible to get arrow keys to work correctly using map! commands, though you can certainly get better behaviour than what happens if you don't map them. :-) You're likely to get your novice users coming in and saying `Why does it move diagonally when I do up-arrow at the start of a line?' , Eamonn
FFAAC09@cc1.kuleuven.ac.be (Nicole Delbecque & Paul Bijnens) (12/21/90)
In article <captaincat@dce.ie>, em@dce.ie (Eamonn McManus) says: > >In comp.unix questions tchrist@convex.COM (Tom Christiansen) writes: >>:Has anyone got a set of 'map!' commands that implement arrow keys in >>:'vi' Input mode? >> >>Yes, I've mailed Richard a uuencoded copy. I posted it very recently in >>comp.editors, so don't think I should post it again here. > >As I (apparently) never tire of pointing out, it's not possible to get >arrow keys to work correctly using map! commands, though you can certainly >get better behaviour than what happens if you don't map them. :-) > >You're likely to get your novice users coming in and saying `Why does it >move diagonally when I do up-arrow at the start of a line?' You can certainly use map! commands for arrow-keys. But you need to be consistent with text-mode vs. command-mode. Do try to hide the mode oriented nature of vi. Just be consistent with your mappings. The convention is: cursor-movement is command mode. Then map cursor movement like this: map ^[[A k map! ^[[A ^[k etc... The command mode map for up-arrow is clear, I think. The input mode map takes you first to command mode, and then just moves. To go back into input mode use i or a or whatever, like you always do. The input maps for cursor movement are just another way to quickly switch to command mode. See it as: vi guesses you want command mode when you hit the cursor-keys, so it switches quickly an moves the cursor. You never "suddenly" change from insert to append mode. The only movement in input mode is backspace (and ^W, which most people use very rare). Most novices find this very consistent (so do I, you mileage may vary...) -- Polleke FFAAC09@cc1.kuleuven.ac.be
em@dce.ie (Eamonn McManus) (12/24/90)
FFAAC09@cc1.kuleuven.ac.be (Nicole Delbecque & Paul Bijnens) write(s): >The convention is: cursor-movement is command mode. >Then map cursor movement like this: > > map ^[[A k > map! ^[[A ^[k > etc... When you end an insertion vi backs up one character unless it is already at the start of the line. So the above map! will cause vi to move up and to the left, except at the start of the line where it will work correctly. Of course if you change the RHS to ^[kl it will work everywhere except at the start of the line (and when the line above is too short). , Eamonn
martin@mwtech.UUCP (Martin Weitzel) (12/28/90)
In article <captaincat@dce.ie> em@dce.ie (Eamonn McManus) writes: >In comp.unix questions tchrist@convex.COM (Tom Christiansen) writes: >>:Has anyone got a set of 'map!' commands that implement arrow keys in >>:'vi' Input mode? >> >>Yes, I've mailed Richard a uuencoded copy. I posted it very recently in >>comp.editors, so don't think I should post it again here. > >As I (apparently) never tire of pointing out, it's not possible to get >arrow keys to work correctly using map! commands, though you can certainly >get better behaviour than what happens if you don't map them. :-) > >You're likely to get your novice users coming in and saying `Why does it >move diagonally when I do up-arrow at the start of a line?' Good point! IMHO it was a very silly thing to try to fake support for Arrow-Keys in insert mode. Besides it doesn't work completly, if you get accustomed to use Arrow-Keys in insert-mode, you will never learn to exploit much of vi-s power that comes with entering insert mode various ways (i,I,s,S, rX, R, cG, cw, ctX, c/regex ...) It was the largest leap I ever achieved in my personal "editing performance" using vi, when I learned about the different ways to start changing something. Really people, learn about that different ways ONCE (1..2 hours, maybe) and it will save you many keystrokes and thereby MANY MORE HOURS you spend editing with vi. The only cooperoation required is to think a little more IN ADVANCE as with other editors, especially you must know "how much do you want to change". It's not hard to get trained to do this, as normaly, when you are editing, this piece of information is allready in your brains - you must just train to use it. The two important questions are: 1) How much must be deleted. 2) How much is to be inserted. Following is a short list of answers with the appropriate commands I usually use to enter insert mode. (Note that this is NOT a complete which shows all the ways to enter insert mode!) Nothing to delete, 1..n characters to insert => i or a or I (%1) Nothing to delete, new stuff in new line(s) => o or O (%1) 1 character to replace by exactly 1 other => r (%2) 1 character to replace by 2..n characters => s 2..n characters to replace by exactly the same number of characters in one line => R (%3, %4) (rest of) current word to replace by 1..n chars => cw or cW (%4) (rest of) sentence to replace by 1..n chars => ct. or cf. (%5) same as before for part of a sentence => ct, or cf, (%5) current line completly to replace by 1..n lines => S (%6) rest of current line to replace by 1..n lines => C current line to end of file to replace by other stuff => cG characters from current position to some pattern to replace by other stuff => c/pattern Now for the remarks in the above recommendations: %1: Using the right command of those given here will save you some moves, e.g. if you insert in a new line, use "o" if the new line is immediatly BELOW the line where the cursor is, and use "O" if you insert ABOVE the line which currently holds the cursor. %2: This command is an exception in so far as you type the new character but need NO additional ESC to return to command mode. %3: If your goal is to change lower case to upper case or vice versa, you might rather want to use "~". This changes the case of the character under the cursor and moves the cursor to the right. %4: Recent versions of vi can be custumized wrt to character classes. This makes these features useful for using vi with character sets that have additional upper- and/or lower case characters (like some European ASCII variants or ISO 8859). %5: Any character can follow the `t' or `f' here, but it must appear in the current line. (Note that this is different with the command c/pattern which may span more than one line!) %6: 2S, 3S etc. may be use to change 2, 3 etc lines (starting with the current line), but I found this only useful when it is easy to count "by eye", i.e. if more than 3 lines are changed it's often too hard to decide quickly, and easier to use "S" to change the first and delete the others after that. Obviously, the last command in the above list is very powerful, and it deserves a few further remarks: Of course, "pattern" means some regular expression as used in other vi/ex commands (search, substitute, global) and so you must be aware of special characters. But more important: If you ever type a faulty pattern and the region that gets replaced spans too many lines (you can check this by the `$' with which vi marks the end of that region), and you hit ESC to correct your fault and now and more or less large parts of your file vanish, (because you just have changed them to nothing) .... ***************** ** DON'T PANIC ** ***************** ... but IMMEDIATLY after ESC hit `u' to <u>ndo the change. -- Martin Weitzel, email: martin@mwtech.UUCP, voice: 49-(0)6151-6 56 83