home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / softsys / andrew / 1172 < prev    next >
Encoding:
Internet Message Format  |  1992-08-25  |  2.3 KB
  1. Path: sparky!uunet!usc!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!ucbvax!ANDREW.CMU.EDU!rr2b+
  2. From: rr2b+@ANDREW.CMU.EDU (Robert Andrew Ryan)
  3. Newsgroups: comp.soft-sys.andrew
  4. Subject: Re: Hasn't the message line bogosity gone on long enough?
  5. Message-ID: <seaklKq00WoiAtIV5V@andrew.cmu.edu>
  6. Date: 26 Aug 92 04:45:10 GMT
  7. References: <weajSh8Gf0470Ta2tc@athena.mit.edu>
  8. Sender: daemon@ucbvax.BERKELEY.EDU
  9. Organization: The Internet
  10. Lines: 48
  11.  
  12. Excerpts from netnews.comp.soft-sys.andrew: 26-Aug-92 Hasn't the message
  13. line bog.. Bill Cattey@ATHENA.MIT.E (436)
  14.  
  15. > Who else here is tired of having the contents of the message line
  16. > dissappear when their pathname happens to be one character too long?
  17.  
  18. Probably everyone...
  19.  
  20. Excerpts from netnews.comp.soft-sys.andrew: 26-Aug-92 Hasn't the message
  21. line bog.. Bill Cattey@ATHENA.MIT.E (436)
  22.  
  23. > Isn't there some sensible way this can be fixed?
  24.  
  25. Almost certainly.
  26.  
  27. Excerpts from netnews.comp.soft-sys.andrew: 26-Aug-92 Hasn't the message
  28. line bog.. Bill Cattey@ATHENA.MIT.E (436)
  29.  
  30. > making the message line fixed with fonts, un justified?
  31.  
  32. Using non-justified text is a step in the right direction, but is not
  33. sufficient.  I don't see the relevance of fixed vs variable width fonts.
  34.  
  35. Excerpts from netnews.comp.soft-sys.andrew: 26-Aug-92 Hasn't the message
  36. line bog.. Bill Cattey@ATHENA.MIT.E (436)
  37.  
  38. > making the message line two lines tall so that people will get the idea
  39. > they really can scroll around in it?
  40.  
  41. Certainly users should be able to have as many message line lines as
  42. they wish.  Perhaps the default should be one line with a special
  43. scrolling icon to the left.  Also some indication should be present if
  44. the latest message cannot be displayed in the available space.  The
  45. message line area should be dynamically resizable in increments of 1
  46. line.  It should also be possible to limit the number of previous
  47. messages kept, and/or total size of messages kept in the history.
  48.  
  49. Even if multi-line message lines become standard, programmers should
  50. strive to insure that most messages are only one line long.  If the
  51. message line has to have more than one line all the time it would
  52. represent quite a bit of wasted real estate.
  53.  
  54. While we're at it how about history based completion for answers?
  55. (Keeping possible answer type completion as well of course.)
  56.  
  57. -Rob Ryan
  58. Andrew Consortium
  59.  
  60.