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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~simon@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>
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
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
rbottin@atl.calstate.edu (Richard John Botting) (12/14/90)
I just caught up with this thread - I notice that nobody explained why the
PC user has such a nasty experience when learning vi. I have been teaching
vi to PC and Mac users (mainly Comp Sci Majors) for 4 or 5 years and have
come to the conclusion that I need a tape recording that says:
DON'T TOUCH THE ARROW KEYS!
To say nothing of Insert, Delete, Home, End, PageUp, Page Down.
Yes - 'vi'+'termcap' can interpret these keys when in command mode.
But - on several systems that my students use the ANSI/vt100/at386/tab132
what-have-you Escape sequence get fouled up - I assume that a buffer
somewhere between the terminal and termcap overflows.
Worse - There is NO command mode in most PC editors. At any point you tap
an arrow key and the cursor moves.
(research in man-machine interfaces shows that modes are bad ergonomics)
In 'vi' (without special "map!" stuff) when the user sees a mistake on the
previous line they tap ESC k j j ... or whatever. The PC user have
developed a conditioned reflex so that there right hand is on the UP arrow
before they remember to move their LEFT hand to the ESCape key...this is
totally automatic. The ESC at the start of the Arrow key gets them
out of insert mode, and (possibly) the following stuff deletes a line, or
worse beeps and almost works...this helps to continue the reflex...
A 'vi' user can simulate this by trying to make a simple text file in
Wordstar or its bastard child TURBO {C, Pascal,...}.
Try it and watch 'i' and 'x' appear (plus 'jjj') when your trying to move.
Its a PAINFUL experience moving from one to the other. BOTH WAYS. I use both.
They foul you up whenever you switch.
It is a pity that this road block can not be reduced because the 'vi'
interface has certain advantages over the WordSplat editors:
Comparision:
Function vi wordstar/TURBO
Add At end of line A CTRL/Q d
Insert before line I CTRL/Q s
Cut line dd CTRL/Q s CTRL/K b KeyDown CTRL/K k
and KeyDown
Paste/put p CTRL/K v
etc
Has anyone got a set of 'map!' commands that implement arrow keys in
'vi' Input mode?
Dr. Richard J. Botting,
Department computer science,
California State University, San Bernardino, CA 92407
paaaaar@calstate.bitnet
rbottin@Atl.calstate.edu
dick@silicon.natsci8.csusbnet.edu ("Real Soon Now")
PAAAAAR%CALSTATE.BITNET@CUNYVM.CUNY.EDU
>INTERNET:PAAAAAR%CALSTATE.BITNET@CUNYVM.CUNY.EDU (Compuserve)
Disclaimer: I am an only an eggkherron@ms.uky.edu (Kenneth Herron) (12/15/90)
rbottin@atl.calstate.edu (Richard John Botting) writes: >...I have been teaching >vi to PC and Mac users (mainly Comp Sci Majors) for 4 or 5 years and have >come to the conclusion that I need a tape recording that says: > DON'T TOUCH THE ARROW KEYS! >To say nothing of Insert, Delete, Home, End, PageUp, Page Down. And from the exception-to-every-rule department: The vi included with System V/386 (3.2.1 in my case), which runs on 80386- equipped AT-compatibles, recognizes the Insert, Home, Page Up, and Page Down keys in or out of insert mode. You can actually move around in the file without leaving insert mode (What'll they think of next? :-). Insert enters insert mode, Home goes to the top left of the screen, PgUp and PgDn move by pages, and the arrow keys move by lines/characters, just as you'd expect. End just beeps, and Delete generates a DEL char, which does nothing useful in my case. The 12 function keys, of course, can be mapped via the usual map mechanism. -- Kenneth Herron kherron@ms.uky.edu University of Kentucky (606) 257-2975 Department of Mathematics I just proved Fermat's last theorem, but .signatures can only be four lines.
tchrist@convex.COM (Tom Christiansen) (12/15/90)
From the keyboard of rbottin@atl.calstate.edu (Richard John Botting): :I just caught up with this thread - I notice that nobody explained why the :PC user has such a nasty experience when learning vi. I have been teaching :vi to PC and Mac users (mainly Comp Sci Majors) for 4 or 5 years and have :come to the conclusion that I need a tape recording that says: : : DON'T TOUCH THE ARROW KEYS! : :To say nothing of Insert, Delete, Home, End, PageUp, Page Down. Absolutely true. I've told them that for 6 years, and they still don't really want to believe me. The worst thing is when they just lean on those keys and get so many interrupts that stuff gets dropped and they find themselves with a mutilated file. :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. If anyone else would care for a copy, mail me and I'll send it to you, but do please be sure to include a good return address in the body. It's got a lot of extra magic in it too for emulating emacs in vi. :-) --tom -- Tom Christiansen 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
les@chinet.chi.il.us (Leslie Mikesell) (12/17/90)
In article <kherron.661202361@s.ms.uky.edu> kherron@ms.uky.edu (Kenneth Herron) writes: >The vi included with System V/386 (3.2.1 in my case), which runs on 80386- >equipped AT-compatibles, recognizes the Insert, Home, Page Up, and Page >Down keys in or out of insert mode. You can actually move around in the >file without leaving insert mode (What'll they think of next? :-). Note, however that it actually does leave insert mode and restart it again, with the corresponding effect on the repeat and undo commands. People who like modelessness probably wouldn't notice this anyway, though. While I think it does make sense to handle the extra PC keyboard keys, I also like to know the boundaries of the "undo" buffer and don't mind hitting escape myself to end an insert. Les Mikesell les@chinet.chi.il.us
FFAAC09@cc1.kuleuven.ac.be (Nicole Delbecque & Paul Bijnens) (12/19/90)
In article <25267@adm.brl.mil>, rbottin@atl.calstate.edu (Richard John Botting) says: > >I just caught up with this thread - I notice that nobody explained why the >PC user has such a nasty experience when learning vi. I have been teaching >vi to PC and Mac users (mainly Comp Sci Majors) for 4 or 5 years and have >come to the conclusion that I need a tape recording that says: > > DON'T TOUCH THE ARROW KEYS! > >To say nothing of Insert, Delete, Home, End, PageUp, Page Down. > >Yes - 'vi'+'termcap' can interpret these keys when in command mode. >But - on several systems that my students use the ANSI/vt100/at386/tab132 >what-have-you Escape sequence get fouled up - I assume that a buffer >somewhere between the terminal and termcap overflows. What you probably have, is an vi-implementation with a not-so-good timeout-feature. Some implementations do an alarm(1)-syscall to timeout multi-character keys. The 1-second resolution can in real-time be anything from 1 second down to 0 (possibly on heavy loaded systems > 1). There is a chance to have a premature timeout (0 seconds!). Mostly the terminal beeps, but if you press the left-arrow key (which sends the codes ESC-[-D) and you get a premature timeout, vi beeps to tell you '[' is not followed by a valid key (expecting another '[') and the 'D' erases to the end of the line. Some keys send sequences beginning with ESC-O-whatever, resulting in an Open line above... Is this what you are experiencing? Then just do ":set notimeout". This helped all those problems away at this site. There is a "gotcha" however. Just pressing <ESC> to stop insert mode now temporarily leaves the cursor at the wrong place. Vi does not yet know what the next key will be: cursor-movement (e.g. ESC-[-A) or a command (e.g. ESC ESC-[-A or ESC 1G). But I can live with that. >In 'vi' (without special "map!" stuff) when the user sees a mistake on the >previous line they tap ESC k j j ... or whatever. The PC user have >developed a conditioned reflex so that there right hand is on the UP arrow >before they remember to move their LEFT hand to the ESCape key...this is >totally automatic. The ESC at the start of the Arrow key gets them >out of insert mode, and (possibly) the following stuff deletes a line, or >worse beeps and almost works...this helps to continue the reflex... >[... stuff deleted ...] >Has anyone got a set of 'map!' commands that implement arrow keys in >'vi' Input mode? Some map! stuff can help as you say. Many people setup arrow keys in insert mode. I hate this. You can setup the input maps for arrow keys to first get out of insert mode and then do the movement, like: map! ^[[A ^[k map ^[[A k etc... This way, IMHO, I feel more consistent with command-mode <-> text-mode. There has been a lot of stuff lately about those mappings and the .exrc files. Never seen how to set up a system wide .exrc file... This is how we do it: In /etc/profile or /etc/cprofile (on SysV.2) or in /etc/rcopts/LOCPRF (on SysV.3) or in .login or .profile if there is no system-wide startup-file... (bourne-shell example:) if [ -r /usr/local/lib/ex/exrc.$TERM ] then EXINIT="so /usr/local/lib/ex/exrc.$TERM" else EXINIT="so /usr/local/lib/ex/exrc.dumb" fi if [ -r $HOME/.exrc ] then EXINIT="$EXINIT|so $HOME/.exrc" fi export EXINIT The directory /usr/local/lib/ex contains mappings for most terminal types in use (some terminals here even have NextPage-keys and other rarely seen keys, why not use them...) (Do not overload these files with mappings not used by most people however!) The directory also contains special purpose setups C-mode etc. If necessary you can setup also $HOME/.exrc.$TERM this way.
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