From: ophof@SERVER.uwindsor.ca (Scott Ophof)
Newsgroups: comp.mail.elm
Subject: More enhancements?
Date: 28 Dec 1992 18:35:31 -0600
Organization: CS Dept, University of Texas at Austin
NNTP-Posting-Host: cs.utexas.edu


More items for the wishlist (maybe already there for 3.x?):
And may I invite discussion for those points not already on the
wishlist for 3.x?

 - Reading and/or writing multiple items at the same time, in any
   case from the same folder, but preferably also from different
   folders.

 - And while writing one item, being able to "flip" to some item
   being read (and back, of course)?

These points actually mean implementing the concept of different
"screens", and maybe levels of screens.  Like this example:

   Entry point
     +-- Help screens
     +-- Aliases  (**)
     |     +-- Related Options
     +-- List-of-Folders
           +-- Related Options
           +-- Index of folder p
           |     +-- Options (for THIS level)
           |     +-- Item FROM person, date, subject
           |     +-- Item FROM person, date, subject
           |     +-- Item TO person, date, subject
           |           +-- Headers-screen (*)
           +-- Index of folder q
           |     +-- Options (for THIS level)
           |     +-- Item FROM person, date, subject
   <*>     |     +-- Item TO person, date, subject
           |     |     +-- Headers-screen (*)
           |     +-- Item TO person, date, subject
           |           +-- Headers-screen (*)
           ....

   The "<*>" would show where one was before displaying this
   navigation screen (for those of us (incl. me) who easily forget
   where we were...).
   Of course a screen showing a tree as above to assist in
   navigation through those screens would be of great help.  :-)
   Of course I don't mean that *all* indices of *all* folders
   would be built; only the one(s) specifically requested...  :-)
   NOTE (*): See further on for comments re headers screen(s).
   NOTE (**): IMHO the aliases facility should be implemented as a
              totally separate thing; it's very useful for so many
              other applications (like "talk", "ftp", "telnet").

 - Another thing is that the headers of an outgoing item are not
   visible while writing the outgoing item.  One needs to drop out
   of edit mode to see the headers (and be very careful *not* to
   accidentally hit RETURN, otherwise it will be sent off...), and
   then re-invoke edit mode to continue.  A key that allows one to
   just "flip" to the headers screen and back is good enough
   already.  :-)
      ("Pine" has the headers in a semi-protected area at the
      beginning of the item being written, and so does RiceMAIL.)
   An option to toggle between having the headers visible (or not)
   in the item being written would be nice.  In any case in
   ".elmrc", but preferably also in the options screen.

 - May I seriously suggest the implementation of a "command line"?
   Where one can type in a whole (set of) command(s) withOUT the
   screen being updated at every key-press?  Where the commands
   would be executed only after RETURN is hit, thus causing only
   *one* screen-update.

 - To go forwards or backwards n screens on the index, one needs
   to either repeatedly hit the relevant cursor (and wait for the
   screen updates), or type an item number.  IMHO a cursor-key
   preceded by a number should indicate how many screens to go
   forwards or backwards.

 - In read mode, "[-]number SPACEBAR" could function as command to
   go forwards or backwards "number" pages, and "[-]number RETURN"
   to go forward/backwards that number of lines.  This seems like
   what's normal in Unix useage, imho...

 - At index level, it would be very handy to be able to see whether
   an incoming item is personal mail, or from some discussion list.
   Most items from ((ex)BITnet) discussion lists are distributed
   with the "Sender:" field containing the name/address of that
   discussion list.
   For those people pulling netnews items into mail and reading/
   replying there, the "Newsgroups:" header performs the same
   function.
   But "elm" as it stands doesn't make use of these headers, and
   thus the user can't discriminate between the two, let alone sort
   on such fields.

 - BTW, being able to (temporarily) "exclude" from display (resp.
   "include") on the index items conforming to some mask would be
   handy too.  Of course one would need a "display all" command to
   restore the display to normal...


Regards.
$$/    (F. Scott Ophof  <ophof@server.uwindsor.ca>)


Newsgroups: comp.mail.elm