From: adam@endor.uucp (Adam Shostack)
Newsgroups: comp.mail.elm
Subject: Re: More enhancements?
Date: 29 Dec 92 17:16:39 GMT
Article-I.D.: das.1992Dec29.171639.3227
Organization: Aiken Computation Lab, Harvard University

In article <9212290038.AA04210@SERVER.uwindsor.ca> ophof@SERVER.uwindsor.ca (Scott Ophof) writes:

>More items for the wishlist (maybe already there for 3.x?):

>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

Please no!  I hate mailers that give me a list of screens before
showing me my mail.  I think that mailers like pine handle mail this
way, and thats fine for people who want it, but please I'd really prefer
that elm be changed to act that way by default.

> - 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.

Good point.  I like the idea of a key flip; perhaps someone could
write an extension to put it in a seperate emacs buffer?  It seems
like this is best handled by the editor being able to grab at a file,
rather than a keypress.  What key will act the same in all editors?

> - 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.

I like this, I'm not quite sure how to implement it.  I often  type
4d, and wish that message 4 would be deleted, instead of hearing about
how there aren't that many messages.  Perhaps a configurable list of
which keys will be acted on at the end of a command?  This does change
the way I'd expect elm to act, so it might not be a hot idea.

> - 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.

A number currently has elm expecting another number, or a return.  If
the ability to add a single character after the number were added,
then this would let me type 4d or 7u, and let you type 3(down arrow).
Comments on how this would work?

> - 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.

Perhaps better would be an optional mode of operation where a message
gets two lines:

6   Nov 10 Sam Finn           (90)   SUMMARY: Data Access Exception
            Sent to Sun Managers mail list (sun-managers@wherever)
or          Posted to comp.mail.elm

> - 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...

How about extend the l)imit display command to understand one or both
of:

!from mark
from !mark

(the first makes more sense to me, but the second also has a degree of
logic to it.)

Adam



Adam Shostack 					adam@das.harvard.edu

What a terrible thing to have lost one's .sig.  Or not to have a .sig
at all.  How true that is.
Newsgroups: comp.mail.elm