home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / unix / question / 13548 < prev    next >
Encoding:
Text File  |  1992-11-17  |  5.8 KB  |  121 lines

  1. Newsgroups: comp.unix.questions
  2. Path: sparky!uunet!ferkel.ucsb.edu!taco!rock!stanford.edu!ames!elroy.jpl.nasa.gov!usc!zaphod.mps.ohio-state.edu!rpi!utcsri!skule.ecf!torn!watserv2.uwaterloo.ca!watmath!undergrad.math.waterloo.edu!papresco
  3. From: papresco@undergrad.math.waterloo.edu (Paul Prescod)
  4. Subject: Re: IS UNIX DEAD? (very long)
  5. Message-ID: <Bxw4B8.HK1@undergrad.math.waterloo.edu>
  6. Organization: University of Waterloo
  7. References: <1992Nov10.055311.14872@wixer.cactus.org> <BxKM0t.1xH@undergrad.math.waterloo.edu> <1992Nov13.033923.872@wixer.cactus.org>
  8. Date: Wed, 18 Nov 1992 02:30:43 GMT
  9. Lines: 110
  10.  
  11. >Mine popped up after 45 seconds (cheap Korean brand).  In the same
  12. >vein, my microwave doesn't ask for confirmation, my light switches
  13. >don't ask for confirmation, and my toilet definitely does not ask
  14. >"are you sure? (y/n)".
  15.  
  16. All of these are considerably easier to use then a text editor.  Many cars
  17. will (rightly) make a sound if you leave your keys in.  They will also
  18. (rightly) make a sound if you leave your lights on when the engine is
  19. off.  It would be (and perhaps is, in some cars) nice if you could turn
  20. these off.  But for my, girlfriend, who is very intelligent, but occasionally
  21. forgets her lights and keys, the buzzers are a Godsend.  And for me, 
  22. who can forget and type qw instead of wq, a prompt "haven't saved yet"
  23. would be nice.  BTW, this is not asking for superflurous time wasting
  24. prompting.  VI will NOT LET YOU QUIT with a Q.  It must be wq or Q!.  So
  25. if I type Q, why not ask me if I meant WQ?  Easier for the user, easeir
  26. for the power user that forgets.
  27.  
  28. >But then, we're arguing apples and oranges, as I said before.  You can't
  29. >do anything useful with a Microsoft Write file except print it, as far
  30. >as I can tell, and I haven't printed anything out in about a month.
  31.  
  32. Or compile it?  write can write ascii as well as VI!
  33.  
  34. >No, assembly is a low level language, C is my favorite programming language,
  35. >and control-c is the de facto standard for process interruption on Unix
  36. >systems.  The bit about kill %1 was facetious, but everyone who intends to
  37. >use Unix seriously should have control-c pretty firmly imbedded in their
  38. >minds.
  39.  
  40. process interruption is different from exit.  Exit implies "update setup
  41. files etc., and perhaps prompt me if I want to save"  Process interruption
  42. implies "quit unconditionally."
  43.  
  44. >Definitely not.  My keyboard doesn't have an F1 key.  If it did, there
  45. >would be no guarantee that it would produce what your F1 key does.
  46. >There are good reasons why nobody uses F-keys -- their original purpose
  47. >was to be bindable to whatever the user felt appropriate.
  48.  
  49. That's fine...your keyboard doesn't have an F1 key and you don't want help.
  50. My keyboard DOES have an F1 key, and unix doesn't have a standard F1 key.
  51. If I want to bind F1 on my computer, having help on it doesn't matter.  Think
  52. about it...it would be intercepted before it gets sent, and translated,
  53. wouldn't it?  And for those of us that don't know how to bind keys yet,
  54. it would go through to help.
  55.  
  56. >You mean one character left, but you're still terminally unconscious.
  57.  
  58. Yes...I keep saying right because I'm thinking about what hand I use to 
  59. type it.
  60.  
  61. >Little bumps on the keyboard don't mandate any sort of cursor control
  62. >arrangement whatsoever.  It makes perfect sense to not use ; for a
  63. >control key -- it's not right of l on all keyboards, for one thing.
  64.  
  65. Non standard QWERTY-incompliant keyboards are certainly not my problem.
  66. 99.9% of qwerty keyboards (and every one I have seen) has a semicolon beside
  67. the l.  The other .1% are so nonstandard that perhaps their hjkl aren't
  68. in a row either.
  69.  
  70. >It does NOT make perfect sense to have an unshifted help key in the
  71. >middle of the goddamn keyboard in an editor people are supposed to use.
  72. >Why don't you take some courses on human-computer interaction and
  73. >ergonomics and try to get back to Unix later?
  74.  
  75. Thus the beauty of the (till now) unused F1 key.  Besides, one would
  76. assume that VI would be configurable enough that you could change the
  77. key mappings of the keys!  Or at least turn off help if you wanted to.
  78.  
  79. >I assume that you meant "if you launch an editor from RN."  Pray tell,
  80. >how does vi figure out from where it was launched, and whether or not
  81. >that program would necessarily need word-wrap on?  Please go on to
  82. >inform me how you've determined that I want word-wrap when I write news --
  83. >I don't -- and how you've managed to instantiate artificial intelligence
  84. >on any other competing system that you're now comparing with Unix?
  85.  
  86. Well, in the PC world (blaspheme!!!!) you tell programs what editor you
  87. want to use and what command line options to send to them.  And guess what
  88. if you want to change that information, you don't have to edit some 
  89. invisible file that the computer has (annoyingly) placed in your work
  90. directory.  The program updates it's OWN config file.  (although you could
  91. do it manually if you're into that kind of thing)
  92.  
  93. >For you, it's a flaw.  For enough other people, it's not.  Your systems
  94. >administrator has decided not to add a file that does something at the
  95. >prompt.  Contact him for further information.
  96.  
  97. I see.  For other people it is a benefit?  Can you explain how it is to 
  98. their benefit to have help do nothing?
  99.  
  100. >If they were, then it would be.
  101.  
  102. They are.
  103.  
  104. >Programs do not decay.  vi is unchallenged as a small, powerful text editor;
  105. >that it was originally written years ago is just not important.
  106.  
  107. B
  108. A
  109. A
  110. A
  111. yes programs DO decay.  See that crap above this line?  That's what
  112. happens when I try to use my arrow keys.  Let's see what happens when
  113. I try to use my f1 key?  Beep.  Where is built in help?  It's not there.
  114.  
  115. VI is decaying.  It is not keeping up with the hardware.  It is not keeping
  116. up with competing software.  Anyone in their right mind given a choice
  117. would not use vi unless they are already familiar with it (or the only
  118. choice is emacs).  
  119.  
  120. Let's not let this decay happen to unix.
  121.