home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / editors / 3154 < prev    next >
Encoding:
Text File  |  1993-01-06  |  1.5 KB  |  34 lines
  1. Newsgroups: comp.editors
  2. Path: sparky!uunet!elroy.jpl.nasa.gov!usc!zaphod.mps.ohio-state.edu!malgudi.oar.net!hyperion!wright!bclaus
  3. From: bclaus@cs.wright.edu (Brian Clausing)
  4. Subject: Re: Odd vi behavior
  5. Message-ID: <1993Jan6.001806.9074@cs.wright.edu>
  6. Organization: Wright State University
  7. References: <fstuart.930105152908@lab16.eng.auburn.edu>
  8. Date: Wed, 6 Jan 1993 00:18:06 GMT
  9. Lines: 23
  10.  
  11. From article <fstuart.930105152908@lab16.eng.auburn.edu>, by fstuart@eng.auburn.edu (Frank Stuart):
  12. > It seems that when I try to edit a file with vi with a filename longer than
  13. > ~66 characters, it stops with a "[Hit return to continue]" message before
  14. > proceeding.  I've tried this with two different version of vi with the same
  15. > results.  If I change TERM to a terminal with >80 characters, I can type
  16. > more characters without the message.  Also, while view behaves similarly,
  17. > ex doesn't seem to care how long the filename is.  Any ideas?
  18. > 
  19. In the versions of vi that I use (Ultrix, System V) the message appears
  20. because the response to a command takes more than one line.  Hence the
  21. program logic gives you an opportunity to see the entire command
  22. response and then repaints the screen after a carriage return.
  23.  
  24. If the tt line is declared longer, the program logic detects multiple-
  25. line messages less frequently.
  26.  
  27. Ex doesn't exhibit this behavior because there is no full-screen
  28. display.
  29.  
  30. The only thing that seems unusual about the behavior of the versions I
  31. use is that it sometimes occurs and is not necessary.
  32.  
  33. Brian Clausing
  34.