home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / mail / elm / 3889 < prev    next >
Encoding:
Internet Message Format  |  1992-12-29  |  4.6 KB
  1. Path: sparky!uunet!cs.utexas.edu!zaphod.mps.ohio-state.edu!uwm.edu!ogicse!das-news.harvard.edu!endor!adam
  2. From: adam@endor.uucp (Adam Shostack)
  3. Newsgroups: comp.mail.elm
  4. Subject: Re: More enhancements?
  5. Message-ID: <1992Dec29.171639.3227@das.harvard.edu>
  6. Date: 29 Dec 92 17:16:39 GMT
  7. Article-I.D.: das.1992Dec29.171639.3227
  8. References: <9212290038.AA04210@SERVER.uwindsor.ca>
  9. Sender: usenet@das.harvard.edu (Network News)
  10. Organization: Aiken Computation Lab, Harvard University
  11. Lines: 100
  12.  
  13. In article <9212290038.AA04210@SERVER.uwindsor.ca> ophof@SERVER.uwindsor.ca (Scott Ophof) writes:
  14.  
  15. >More items for the wishlist (maybe already there for 3.x?):
  16.  
  17. >These points actually mean implementing the concept of different
  18. >"screens", and maybe levels of screens.  Like this example:
  19. >
  20. >   Entry point
  21. >     +-- Help screens
  22. >     +-- Aliases  (**)
  23. >     |     +-- Related Options
  24. >     +-- List-of-Folders
  25.  
  26. Please no!  I hate mailers that give me a list of screens before
  27. showing me my mail.  I think that mailers like pine handle mail this
  28. way, and thats fine for people who want it, but please I'd really prefer
  29. that elm be changed to act that way by default.
  30.  
  31. > - Another thing is that the headers of an outgoing item are not
  32. >   visible while writing the outgoing item.  One needs to drop out
  33. >   of edit mode to see the headers (and be very careful *not* to
  34. >   accidentally hit RETURN, otherwise it will be sent off...), and
  35. >   then re-invoke edit mode to continue.  A key that allows one to
  36. >   just "flip" to the headers screen and back is good enough
  37. >   already.  :-)
  38. >      ("Pine" has the headers in a semi-protected area at the
  39. >      beginning of the item being written, and so does RiceMAIL.)
  40. >   An option to toggle between having the headers visible (or not)
  41. >   in the item being written would be nice.  In any case in
  42. >   ".elmrc", but preferably also in the options screen.
  43.  
  44. Good point.  I like the idea of a key flip; perhaps someone could
  45. write an extension to put it in a seperate emacs buffer?  It seems
  46. like this is best handled by the editor being able to grab at a file,
  47. rather than a keypress.  What key will act the same in all editors?
  48.  
  49. > - May I seriously suggest the implementation of a "command line"?
  50. >   Where one can type in a whole (set of) command(s) withOUT the
  51. >   screen being updated at every key-press?  Where the commands
  52. >   would be executed only after RETURN is hit, thus causing only
  53. >   *one* screen-update.
  54.  
  55. I like this, I'm not quite sure how to implement it.  I often  type
  56. 4d, and wish that message 4 would be deleted, instead of hearing about
  57. how there aren't that many messages.  Perhaps a configurable list of
  58. which keys will be acted on at the end of a command?  This does change
  59. the way I'd expect elm to act, so it might not be a hot idea.
  60.  
  61. > - To go forwards or backwards n screens on the index, one needs
  62. >   to either repeatedly hit the relevant cursor (and wait for the
  63. >   screen updates), or type an item number.  IMHO a cursor-key
  64. >   preceded by a number should indicate how many screens to go
  65. >   forwards or backwards.
  66.  
  67. A number currently has elm expecting another number, or a return.  If
  68. the ability to add a single character after the number were added,
  69. then this would let me type 4d or 7u, and let you type 3(down arrow).
  70. Comments on how this would work?
  71.  
  72. > - At index level, it would be very handy to be able to see whether
  73. >   an incoming item is personal mail, or from some discussion list.
  74. >   Most items from ((ex)BITnet) discussion lists are distributed
  75. >   with the "Sender:" field containing the name/address of that
  76. >   discussion list.
  77. >   For those people pulling netnews items into mail and reading/
  78. >   replying there, the "Newsgroups:" header performs the same
  79. >   function.
  80. >   But "elm" as it stands doesn't make use of these headers, and
  81. >   thus the user can't discriminate between the two, let alone sort
  82. >   on such fields.
  83.  
  84. Perhaps better would be an optional mode of operation where a message
  85. gets two lines:
  86.  
  87. 6   Nov 10 Sam Finn           (90)   SUMMARY: Data Access Exception
  88.             Sent to Sun Managers mail list (sun-managers@wherever)
  89. or          Posted to comp.mail.elm
  90.  
  91. > - BTW, being able to (temporarily) "exclude" from display (resp.
  92. >   "include") on the index items conforming to some mask would be
  93. >   handy too.  Of course one would need a "display all" command to
  94. >   restore the display to normal...
  95.  
  96. How about extend the l)imit display command to understand one or both
  97. of:
  98.  
  99. !from mark
  100. from !mark
  101.  
  102. (the first makes more sense to me, but the second also has a degree of
  103. logic to it.)
  104.  
  105. Adam
  106.  
  107.  
  108.  
  109. Adam Shostack                     adam@das.harvard.edu
  110.  
  111. What a terrible thing to have lost one's .sig.  Or not to have a .sig
  112. at all.  How true that is.
  113.