home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / mail / elm / 3864 < prev    next >
Encoding:
Internet Message Format  |  1992-12-28  |  4.6 KB
  1. Path: sparky!uunet!think.com!yale.edu!qt.cs.utexas.edu!cs.utexas.edu!gateway
  2. From: ophof@SERVER.uwindsor.ca (Scott Ophof)
  3. Newsgroups: comp.mail.elm
  4. Subject: List of enhancements
  5. Date: 28 Dec 1992 03:29:35 -0600
  6. Organization: CS Dept, University of Texas at Austin
  7. Lines: 88
  8. Sender: daemon@cs.utexas.edu
  9. Message-ID: <9212280932.AA14332@SERVER.uwindsor.ca>
  10. NNTP-Posting-Host: cs.utexas.edu
  11.  
  12.  
  13. Having read the documentation on "elm", and in character with
  14. the feeling that emanates from it (to give the user something
  15. much better than other available MUAs), I'd like to offer some
  16. suggestions and requests for improvements to "elm".
  17.  
  18. Friendlier and more "intelligent" display of ones folders:
  19. Instead of that scrolling of the list, and of course discovering
  20. that the folder one wanted has already gone off-screen before being
  21. able to fully read it, why not present the display in screenfuls,
  22. each of which can be selected SEPARATELY.  And when the last folder
  23. is visible, then *PLEASE* NOT automatically "roll off the end"?
  24.  - This could be done using the "<" and ">" keys to select which page
  25.    one wants to skip to for display, and RETURN to quit the display.
  26.  - And how about allowing one to use the TAB key to skip to each
  27.    folder name in turn, with the SPACE key informing "elm" of the
  28.    folder one wishes to change to?
  29.  - And the cursor keys (and/or the "hjkl" keys) to assist in this
  30.    positioning of the cursor in the right spot?
  31.  
  32. What about allowing invocation of "elm" from within itself?
  33. It's strange that one cannot take a "side-look" at some item in
  34. another folder than the one currently referenced without first
  35. having to quit that folder, "change" to the other folder, wait for
  36. its index to be built, find the item, invoke the pager, SPACE down
  37. to what one is looking for, quit the item, "change" back to the
  38. original folder, wait again for the (unnecessary) index re-build,
  39. etc., etc...
  40. And it's even more frustrating when having to do a side-check while
  41. building an item to *send*!  :-(
  42.  
  43. Unix boasts being able to be used from almost any terminal
  44. imaginable.  It's strange then that no application I've come across
  45. up to now realizes that when a user wants to skip straight to (say)
  46. the 4th page by hitting SPACE 4 times, one still needs to wait for
  47. each of those pages to be laboriously built and displayed onscreen
  48. (line by molasses-slow line at 2400 bps...) before going on to the
  49. next.  Isn't there any way for a program to detect that it has been
  50. requested to already display the next screen before it has ended
  51. updating the current screen?
  52. My question here is whether it's at all possible in Unix, and if so,
  53. why it has never been implemented?  It seems so *obvious* to me...
  54. Unix is a full-duplex system, so it *should* be possible.  And I
  55. know from experience that it *is* possible and common on half-
  56. duplex systems...
  57.  
  58. As to aliases, how about enhancing that facility to allow users to
  59. include such things like which folder to store items in related to a
  60. specific alias, phone numbers, surface addresses, user-definable
  61. fieldnames and -values?  Especially if the facility were not
  62. integral to "elm" anymore, but invocable from "elm" as a separate
  63. utility, which then could also be used by other applications.
  64. If this were implemented, then the very limited and not-really-so-
  65. useful relevant parameters in ".elmrc" would at last become
  66. obsolete.  :-)
  67. And maybe a separate screen to display field-names and -values of an
  68. alias entry, both for input and display?  And being able to cycle
  69. through the entries forwards and backwards?
  70.  
  71. Another thing is the possibility of retaining the index of a folder
  72. (as an on-disk file) as long as the relevant folder doesn't change.
  73. Skipping the index-rebuild each time for folders containing many
  74. items would save quite some wall-clock and CPU time (at the expense
  75. of some disk space, of course).
  76. In addition, an option like:
  77.    saveindex=[yes|no|number]
  78. (where "number" would be the minimum number of items at which to
  79. start saving the index) would still give the user control over this
  80. option.
  81.  
  82. A more friendly built-in browser when reading items would also be
  83. appreciated.  One where paging commands are supported, both
  84. forwards, but especially BACKwards!  And at least per screen and
  85. half-screen, preferably in any increment the user wishes.
  86. And NOT automatically "run off the end", *PLEASE*!
  87. The built-in pager does NOT seem to support such commands, nor do
  88. "more" (and "less")...
  89. BTW, I do *not* see "vi" or "e-macs" (or rough equivs) as viable
  90. alternatives.
  91.  
  92. Please, implement redraw for each and every separate kind of screen
  93. displayable, not only for the index; some phone lines are really
  94. *terrible*!
  95.  
  96.  
  97. Regards.
  98. $$/
  99.  
  100.