johnj@osiris.UUCP (John Johnston johnj@welch.jhu.edu) (07/31/89)
We've been considering setting ELM up as our 'default' mailer for non-sophisticated users. Part of the requests that I've been getting back from the people who are doing evaluation are: - ability to pass the verbose flag off to sendmail from within the elmrc file rather than command line. IMHO, command lines and .rc files should always support complete operation on eachother - they should totally overlap. (this is easy and took me a second to add) - some means whereby the mailer could be told to 'time-out' if left inactive for too long. It would be nice if there was a way to tell the mailer to save itself and quit after a certain amount of idle time. This is probably not generally useful to the world at large - when I add it, will anyone be interested ? - some kind of simple visual editor. My user community is used to using the arrow keys on the keyboard to move around, and other PC-type editing stuff. If someone has a simple in-memory screen editor with key-mapping, that would be nice to plug in. Calling an external program (we are using microemacs with a minimal configuration) is slow, and a more powerful builtin editor would be great. - some ability to redefine command keys. I've considered attacking this one myself. I don't think it would be too hard to hack the functions that read command characters to allow some redefinition of keys. Non "vi" users and people who are used to PCs fail to grasp the complex reasons why the 'up' key is 'k' instead of up-arrow, etc. Comments ? --mjr();
syd@DSI.COM (Syd Weinstein) (07/31/89)
johnj@osiris.UUCP (John Johnston johnj@welch.jhu.edu) writes:
: We've been considering setting ELM up as our 'default' mailer
:for non-sophisticated users. Part of the requests that I've been getting
:back from the people who are doing evaluation are:
: - ability to pass the verbose flag off to sendmail
: from within the elmrc file rather than command
: line. IMHO, command lines and .rc files should
: always support complete operation on eachother -
: they should totally overlap.
: (this is easy and took me a second to add)
We don't put every option in the rc file into the command line because
there are too many of them, it would get overly confusing. Remember
getopt parses single letters. However, I guess we could try and
create a override rc option that takes the name and value, but that
would be a pain to type. Its definately a high priority item anyway.
: - some means whereby the mailer could be told to 'time-out'
: if left inactive for too long. It would be nice
: if there was a way to tell the mailer to save
: itself and quit after a certain amount of idle
: time. This is probably not generally useful to
: the world at large - when I add it, will anyone
: be interested ?
This is actually backwards from how alot of us use Elm. We start
it up in a window and let it sit there. Using its internal timout
loop to refresh the current mail status. Since it was designed to
stay active in a window, I think this is backwards from the design
goal.
: - some kind of simple visual editor. My user community is
: used to using the arrow keys on the keyboard to
: move around, and other PC-type editing stuff. If
: someone has a simple in-memory screen editor with
: key-mapping, that would be nice to plug in. Calling
: an external program (we are using microemacs with a
: minimal configuration) is slow, and a more powerful
: builtin editor would be great.
Elm is big enough already without some editor also. I recommend using
a small outboard editor, that way the start up time will be small.
Emacs' startup time is not small, and perhaps a lot of the time is
there.
: - some ability to redefine command keys. I've considered
: attacking this one myself. I don't think it would
: be too hard to hack the functions that read command
: characters to allow some redefinition of keys. Non
: "vi" users and people who are used to PCs fail to
: grasp the complex reasons why the 'up' key is 'k'
: instead of up-arrow, etc.
Not easy to do, remember, we do not use curses at the present, thus
we do our own key work, internally. Also, you need to handle timeouts
vs function keys, etc. We even punted handling other than HP and ANSI
cursor keys (which currently do work) until after curses is in, and
currently we are even punting curses due to its problems on many machines.
Lastly, if you are making changes to Elm, why not join the Elm
development group and let others share in your changes.
--
=====================================================================
Sydney S. Weinstein, CDP, CCP Elm Coordinator
Datacomp Systems, Inc. Voice: (215) 947-9900
syd@DSI.COM or {bpa,vu-vlsi}!dsinc!syd FAX: (215) 938-0235scs@itivax.iti.org (Steve Simmons) (07/31/89)
syd@DSI.COM (Syd Weinstein) writes: >johnj@osiris.UUCP (John Johnston johnj@welch.jhu.edu) writes: >: - some means whereby the mailer could be told to 'time-out' >: if left inactive for too long . . . >This is actually backwards from how alot of us use Elm. We start >it up in a window and let it sit there. Using its internal timout >loop to refresh the current mail status. Since it was designed to >stay active in a window, I think this is backwards from the design >goal. Yes, but John has a point. I think his request is eminently doable, and would not conflict with current usage. I would implement it such that a new elmrc option is defined, maximum-idle. It's default would be zero, ie, no maximum. This can be implemented without breaking the current mail-checking alarms as well. If there's agreement among the development group (and John doesn't volunteer) I'll take a swat at it. -- Steve Simmons scs@vax3.iti.org Industrial Technology Institute Ann Arbor, MI. "Velveeta -- the Spam of Cheeses!" -- Uncle Bonsai
solomon@gjetost.cs.wisc.edu (Marvin Solomon) (07/31/89)
In article <1989Jul31.012922.12548@DSI.COM> syd@DSI.COM writes: >johnj@osiris.UUCP (John Johnston johnj@welch.jhu.edu) writes: > >: - some means whereby the mailer could be told to 'time-out' >: if left inactive for too long. It would be nice >: if there was a way to tell the mailer to save >: itself and quit after a certain amount of idle >: time. This is probably not generally useful to >: the world at large - when I add it, will anyone >: be interested ? >This is actually backwards from how alot of us use Elm. We start >it up in a window and let it sit there. Using its internal timout >loop to refresh the current mail status. Since it was designed to >stay active in a window, I think this is backwards from the design >goal. I think I know what he means: I too like to leave Elm running all day, but sometimes I forget to exit before going home, and then when I try to read my mail from home, I get the "sorry, Elm is already running" message. I can kill the process, but that effectively does a 'x', which means that all the sorting and winnowing I've done all day is lost (and I get about 100 messages each day). I've hacked in some changes that catch SIGTERM and effectively do a 'Q' command (actually, a sequence of 'Q' commands, since 'Q' doesn't always get you out the first time). It should be easy to cobble up a elmquit command using ps, grep, and kill. I'll post the mods to this group after I'm reasonably confident they work. > >Lastly, if you are making changes to Elm, why not join the Elm >development group and let others share in your changes. What does that entail? Can't one simple contribute stuff without joining a development group? -- Marvin Solomon Computer Sciences Department University of Wisconsin, Madison WI solomon@cs.wisc.edu, uwvax!solomon
frankb@usource.UUCP (Frank Bicknell) (08/03/89)
In article <8046@spool.cs.wisc.edu> solomon@gjetost.cs.wisc.edu (Marvin Solomon) writes: > In article <1989Jul31.012922.12548@DSI.COM> syd@DSI.COM writes: > >johnj@osiris.UUCP (John Johnston johnj@welch.jhu.edu) writes: > > > >: - some means whereby the mailer could be told to 'time-out' > >: if left inactive for too long. It would be nice > > >This is actually backwards from how alot of us use Elm. We start > >it up in a window and let it sit there. ... > > I think I know what he means: I too like to leave Elm running > all day ... hmmmm... What's the advantage over just running 'newmail' in the background? It tells me when mail arrives right away (well, within the minute) instead of having to go to some other screen or window or whatever to check to see what's there. True, it scrambles the screen, but _most_ applications have a redraw and certainly vi does (my most-used application). Is there some reason why you guys like to use elm to do newmail's job? -- Frank Bicknell UniSource; 1405 Main St, Ste 709; Sarasota, FL 34236 attctc!usource!frankb || frankb@usource.UUCP
jeff@quark.WV.TEK.COM (Jeff Beadles) (08/05/89)
In article <230@usource.UUCP> frankb@usource.UUCP (Frank Bicknell) writes: > >Is there some reason why you guys like to use elm to do >newmail's job? Well, for one I use an X11-window workstation for my day-to-day work. I have a window that sits iconified on the top-right side of my screen that has elm running all day. I've got it set-up to "auto-deiconify-on-output" so when Elm notices that I have new mail, it pops open for me. To run {w}newmail, 'twould be a bit of a waste. I STILL need to start-up elm to read my mail. (not really, if you count readmsg. :-) -Jeff -- Jeff Beadles Utek Sustaining Engineering, Tektronix Inc. jeff@quark.WV.TEK.COM Member of the Elm development group.