steve@raspail.UUCP (Steve Schonberger) (12/13/88)
One neat feature that I think would be good to have in elm is the Return-Receipt-To: header line. It would be nice enough just to have it there so I don't have to type out that header name in a user defined header, and incredibly great to be able to have it generated automatically. I imagine adding a non-smart return receipt line would be pretty simple, and ask that it be considered in the development effort. I may try hacking it in myself, if I feel ambitious enough. I suspect that a smart return receipt generator would be quite a nasty task, and likely very non-portable. I would not expect it to be workable as a quick hack to get it into the next release, except possibly if it were set to a default that was compiled in to sites that have a domain address that works from about anywhere. One of my friends has an x.400 mailer, and her system does have a smart return receipt generator, but porting x.400 specific features to a UUCP based mailer seems as bad as writing it from scratch. A possible semi-portable system for the job, for systems with the pathalias database present, would be to look up the smail path to the intended site, and reverse it. I can't imagine making that work properly for multiple receipients though. Keep up the good work! Steve Schonberger steve@raspail.uucp raspail!steve@shamash.cdc.com ...!uunet!rosevax!shamash!rapail!steve
rob@pbhyf.PacBell.COM (Rob Bernardo) (12/13/88)
In article <1094@raspail.UUCP> steve@raspail.UUCP (Steve Schonberger) writes:
+One neat feature that I think would be good to have in elm is the
+ Return-Receipt-To:
+header line. It would be nice enough just to have it there so I
+don't have to type out that header name in a user defined header,
+and incredibly great to be able to have it generated automatically.
This can easily be accomplished by creating an elmheaders file.
If you have using ELM 2.1 (or later version) this file resides
in your .elm directory. For earlier versions you need a $HOME/.elmheaders
file.
When you mail a message, the contents of this file are included after
the standard mail headers but before the newline that begins the message
body.
--
Rob Bernardo, Pacific Bell UNIX/C Reusable Code Library
Email: ...![backbone]!pacbell!pbhyf!rob OR rob@pbhyf.PacBell.COM
Office: (415) 823-2417 Room 4E750A, San Ramon Valley Administrative Center
Residence: (415) 827-4301 R Bar JB, Concord, Californiadarrell@mcdurb.Urbana.Gould.COM (12/15/88)
/* Written 12:50 am Dec 13, 1988 by rob@pbhyf.PacBell.COM in mcdurb:comp.mail.elm */ > In article <1094@raspail.UUCP> steve@raspail.UUCP (Steve Schonberger) writes: > +One neat feature that I think would be good to have in elm is the > + Return-Receipt-To: > +header line. It would be nice enough just to have it there so I > +don't have to type out that header name in a user defined header, > +and incredibly great to be able to have it generated automatically. > > This can easily be accomplished by creating an elmheaders file. > If you have using ELM 2.1 (or later version) this file resides > in your .elm directory. For earlier versions you need a $HOME/.elmheaders > file. > > When you mail a message, the contents of this file are included after > the standard mail headers but before the newline that begins the message > body. Yes, you can put the header in your .elmheaders file but then it goes out with every message. Many times I've wanted to be able to include it with some messages but not others. Having to type such a long string as a user defined header is a real pain too, especially if you don't type well. Having it show up in the headers menu would be nice but selecting this item would conflict with the Reply-To: header; elm uses the first letter of the header as the selection key. Some other scheme would have to be used or the Reply-To: header removed from the menu. Perhaps each header in the menu could be numbered and selection made by number instead of first letter. -- Darrell McIntosh, Motorola Microcomputer Division, Urbana [IL] Design Center Phone: +1 217 384 8509 Email: darrell@urbana.mcd.mot.com, mcdurb!darrell, uunet!uiucuxc!mcdurb!darrell
peter@ficc.uu.net (Peter da Silva) (12/15/88)
In article <51900010@mcdurb>, darrell@mcdurb.Urbana.Gould.COM writes: > Having it show up in the headers menu would be nice but selecting this > item would conflict with the Reply-To: header; elm uses the first letter > of the header as the selection key... The headers menu is the problem, not the solution. A solution is to just do what the 'reply' function in news does, and let the user edit the headers with their usual editor. Put all the headers in, let them edit their message, then read them all back and delete the ones the user leaves empty. -- Peter da Silva `-_-' Ferranti International Controls Corporation "Have you hugged U your wolf today?" uunet.uu.net!ficc!peter Disclaimer: I accept full responsibility for my typos. peter@ficc.uu.net
rob@pbhyf.PacBell.COM (Rob Bernardo) (12/16/88)
In article <2454@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: +In article <51900010@mcdurb>, darrell@mcdurb.Urbana.Gould.COM writes: +> Having it show up in the headers menu would be nice but selecting this +> item would conflict with the Reply-To: header; elm uses the first letter +> of the header as the selection key... + +The headers menu is the problem, not the solution. A solution is to just +do what the 'reply' function in news does, and let the user edit the +headers with their usual editor. Put all the headers in, let them edit their +message, then read them all back and delete the ones the user leaves empty. That solution as is would go against the grain of ELM's philosophy of being user friendly for both sophisticated *and* unsophisticated users. -- Rob Bernardo, Pacific Bell UNIX/C Reusable Code Library Email: ...![backbone]!pacbell!pbhyf!rob OR rob@pbhyf.PacBell.COM Office: (415) 823-2417 Room 4E750A, San Ramon Valley Administrative Center Residence: (415) 827-4301 R Bar JB, Concord, California
prc@maxim.ERBE.SE (Robert Claeson) (12/16/88)
In article <1094@raspail.UUCP>, steve@raspail.UUCP (Steve Schonberger) writes: > One neat feature that I think would be good to have in elm is the > Return-Receipt-To: > header line. ... and the ability to have more than one U)ser defined header, and the ability to set user defined headers when I invoke ELM 2.1PL1 with "elm user@dom.ain". -- Robert Claeson, ERBE DATA AB, P.O. Box 77, S-175 22 Jarfalla, Sweden Tel: +46 758-202 50 EUnet: rclaeson@ERBE.SE uucp: uunet!erbe.se!rclaeson Fax: +46 758-197 20 Internet: rclaeson@ERBE.SE
syd@dsinc.UUCP (Syd Weinstein) (12/16/88)
In article <2454@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >The headers menu is the problem, not the solution. A solution is to just >do what the 'reply' function in news does, and let the user edit the >headers with their usual editor. Put all the headers in, let them edit their >message, then read them all back and delete the ones the user leaves empty. I disagree that the header menu is the problem. Remember that Elm is a mailing system for users from Novices to Guru's. Novices cannot handle an editor. Note that it is possible to build mail and read it from Elm with out using any Editor at all. Forcing them to use an editor is wrong. Perhaps allowing it for the Guru's isnt wrong, but you still need to have a way for the novices to handle things without the editor. -- ===================================================================== Sydney S. Weinstein, CDP, CCP Elm Coordinator Datacomp Systems, Inc. Voice: (215) 947-9900 {allegra,bellcore,bpa,vu-vlsi}!dsinc!syd FAX: (215) 938-0235
peter@ficc.uu.net (Peter da Silva) (12/17/88)
I suggested letting the user edit the menus directly... > +Put all the headers in, let them edit their > +message, then read them all back and delete the ones the user leaves empty. In article <4408@pbhyf.PacBell.COM>, rob@pbhyf.PacBell.COM (Rob Bernardo) writes: > That solution as is would go against the grain of ELM's philosophy of > being user friendly for both sophisticated *and* unsophisticated > users. Well, let me say this about that... (1) There *is* an expert mode switch. (2) VNEWS does this right now, without confusing people. (3) The headers menu is unfriendly for sophisticated users. Alternatives... (1) As above, let the user edit the headers at will. (2) Like (1), but make it an option in expert mode. (3) Fix the headers menu... arbitrary strings, let the user select header items with cursor keys, etc... (4) Let the user specify an external preparation program, which does like (1). The default would act like the current one: splits the headers out and provides a seperate editing menu. Then I could specify "/bin/vi". (5) Do (4), and also do (3). Well, part 22 just made it here. Time to build me a new Ellum. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Work: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Home: bigtex!texbell!sugar!peter, peter@sugar.uu.net.
steve@raspail.UUCP (Steve Schonberger) (12/17/88)
> > In article <1094@raspail.UUCP>, I wrote: > > +One neat feature that I think would be good to have in elm is the > > + Return-Receipt-To: > > +header line. > Written 12:50 am Dec 13, 1988 by rob@pbhyf.PacBell.COM: > > This can easily be accomplished by creating an elmheaders file. In article <51900010@mcdurb>, darrell@mcdurb.Urbana.Gould.COM writes: > Yes, you can put the header in your .elmheaders file but then it goes > out with every message. [...] This is one thing that bothers me about the elmheaders solution to the problem. From an in town site, I'd like my return address to show up as "raspail!steve", but from a distant site "uunet!rosevax!raspail!steve" works better. I don't want a receipt at all on mail withing this machine especially if it has to go all the way to uunet just to come back. That is the reason I expressed interest in having a smart receipt generator in my original posting. Making it a menu item would be a good as a "keep it simple, stupid" solution, and be _much_ more portable. > Having it show up in the headers menu would be nice but selecting this > item would conflict with the Reply-To: header; elm uses the first letter > of the header as the selection key. Some other scheme would have to be > used or the Reply-To: header removed from the menu. Perhaps each header > in the menu could be numbered and selection made by number instead of > first letter. No, _please_ not numbered menu items! I think a better solution for this would be to have "Reply-To:" be menu item "r", and "Return-Receipt-To:" be menu item "R". Sure, making things case sensitive isn't as friendly as a lot of things in elm, but it sure beats numbered headers! For people who want to avoid the shift key, it might be nice to have a particular special character as an alias for "R".
les@chinet.chi.il.us (Leslie Mikesell) (12/19/88)
In article <40@dsinc.UUCP> syd@dsinc.UUCP (Syd Weinstein) writes: >Novices cannot >handle an editor. Note that it is possible to build mail and read >it from Elm with out using any Editor at all. Forcing them to use >an editor is wrong. Perhaps allowing it for the Guru's isnt wrong, >but you still need to have a way for the novices to handle things >without the editor. Um, perhaps you mean you can build mail without an *external* editor. I doubt if a novice knows or cares if the editor is internal or not. How about allowing rn-like % escapes to specify what is pre-written to the edit buffer for those who want to see what elm is planning to do, and allow any headers typed in the text to override the defaults, merging in any totally new headers. This would have the advantage of being invisible unless the elmrc is modified but would not require the change just to gain the ability to add a non-standard header. If you think that someone is dumb enough to start a message with: TO: you FROM: me then maybe a special line should be required at the beginning to indicate that headers are present (something unusual enough that it is not likely to appear by accident). Les Mikesell
jv@mhres.mh.nl (Johan Vromans) (12/19/88)
From article <40@dsinc.UUCP>, by syd@dsinc.UUCP (Syd Weinstein): > [...] Remember that Elm is > a mailing system for users from Novices to Guru's. Novices cannot > handle an editor. I do not agree. The problem is not the editor, but which editor. A user-friendly full-screen editor which uses standard type commands (e.g. what you type is what you get) and the terminal cursor and page keys is a great companion for novice Elm. In my company Elm is used as the primary mail interface most notably for managers and other non-gurus. [Editor wars to /dev/null, please] On the other hand, to make Elm more useful for novice users: - provide a restricted mode, in which most of the powefull commands are disabled. - require command names and *MOST IMPORTANT:* answers to questions to be terminated with a RETURN. Current Yes/No questions take ANY input and what happens depends on the coding. - support the terminal cursor and paging keys in all menu's. When an entry from the maile menu is high-lighted, the most natural way to select another entry is using the arrow-keys. Useful for all users: - provide for a means to pass a pre-formatted message to Elm. This allows Elm to be called from application programs (e.g. the News programs) with a pre-formatted message which can be edited from Elm if desired. -- Johan Vromans jv@mh.nl via european backbone (mcvax) Multihouse [A-Za-z ]* [NB]V uucp: ..!mcvax!mh.nl!jv Gouda - The Netherlands phone: +31 1820 62944
randy@cctb.mn.org (Randy Orrison) (12/19/88)
In article <40@dsinc.UUCP> syd@dsinc.UUCP (Syd Weinstein) writes: | Perhaps allowing it for the Guru's isnt wrong, but you still need to | have a way for the novices to handle things without the editor. I think a mechanism like the 'pager' variable is a good solution. Have a 'header-editor' that defaults to 'builtin' which gives the current menu system, but can be set to some external editor (emacs!) in which case elm will create a file with the headers in it and allow the user to edit that file. This gives the default, simple behavior for novices, and still allows much more powerful capabilities for gurus. -randy -- Randy Orrison - Chemical Computer Thinking Battery - randy@cctb.mn.org (aka randy@{umn-cs.uucp, ux.acss.umn.edu, umnacvx.bitnet, halcdc.uucp}) "Blow a lawyer to pieces / It's the obvious way Don't wait for a thesis / Do it today" - Al Stewart
rob@pbhyf.PacBell.COM (Rob Bernardo) (12/20/88)
In article <40@dsinc.UUCP> syd@dsinc.UUCP (Syd Weinstein) writes: + Perhaps allowing it for the Guru's isnt wrong, but you still need to + have a way for the novices to handle things without the editor. In article <154@cctb.mn.org> randy@cctb.UUCP (Randy Orrison) writes: +I think a mechanism like the 'pager' variable is a good solution. Have +a 'header-editor' that defaults to 'builtin' which gives the current +menu system, but can be set to some external editor (emacs!) in which +case elm will create a file with the headers in it and allow the user to +edit that file. This gives the default, simple behavior for novices, +and still allows much more powerful capabilities for gurus. Randy, I think you missed the overall point. "Beneath" the discussion of how to edit the headers was a discussion of introducing a new header "Return-Receipt-To:". It cannot be simply added to the current ELM header editing screen because individual headers are selected for editing by the user entering their first letter and unfortunately "r" is already taken up by "Reply-To:". Syd's point was that while introducing an option whereby expert users could edit the headers in the same temp file as the body of the letter (i.e. with vi or whatever their editor of choice is), novice users would still be restricted to the old ELM header editing screen. The latter would need some non-trivial user-impacting design changes to accomodate this new header line. So we are still left with the question of how the best way to change the operation of the ELM header editing screen whether or not we allow expert users to edit the headers along with the message body. -- Rob Bernardo, Pacific Bell UNIX/C Reusable Code Library Email: ...![backbone]!pacbell!pbhyf!rob OR rob@pbhyf.PacBell.COM Office: (415) 823-2417 Room 4E750A, San Ramon Valley Administrative Center Residence: (415) 827-4301 R Bar JB, Concord, California
jbayer@ispi.UUCP (Jonathan Bayer) (12/20/88)
In article <2706@mhres.mh.nl>, jv@mhres.mh.nl (Johan Vromans) writes: > From article <40@dsinc.UUCP>, by syd@dsinc.UUCP (Syd Weinstein): [ comments deleted] > > On the other hand, to make Elm more useful for novice users: > > - provide a restricted mode, in which most of the powefull > commands are disabled. This would be fairly easy to do (I think) > - require command names and *MOST IMPORTANT:* answers to > questions to be terminated with a RETURN. Current Yes/No > questions take ANY input and what happens depends on the > coding. Extremely necessary, especially for novices and noisy dial-up lines > - support the terminal cursor and paging keys in all menu's. > When an entry from the maile menu is high-lighted, the most > natural way to select another entry is using the arrow-keys. > Yes Having just installed Elm 2.1 PL 1, I can only say that it is a very well implemented system. However, I have looked at the source code and have had difficulty following some of the logic due to the odd indentation style. I will be making some local mods which might cover some of the above items. If I do I will either post the mods or send them to the development group. Jonathan Bayer Intelligent Software Products, Inc.
peter@ficc.uu.net (Peter da Silva) (12/21/88)
In article <4417@pbhyf.PacBell.COM>, rob@pbhyf.PacBell.COM (Rob Bernardo) writes: > Randy, I think you missed the overall point. "Beneath" the discussion > of how to edit the headers was a discussion of introducing a new > header "Return-Receipt-To:". Let the user select headers with the cursor keys, the same way they select messages in the main elm menu. In fact, this could be combined with my earlier suggestion for passing the header info to the message editor. Just give the novices a message editor that strips out the headers, edits the message using their editor, and then goies into the elm header editor. Experts would just take this whole unit out of the loop. What's more, it'd make the main program smaller. Those of us with 80286 based machines would benefit from this as well. The downside is that you would have to replace huge sections of the header editor. And no, I'm not ready to do this myself. I'm still trying to get elm to work on Xenix 286. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Work: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Home: bigtex!texbell!sugar!peter, peter@sugar.uu.net.
rob@pbhyf.PacBell.COM (Rob Bernardo) (12/21/88)
In article <2510@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes:
+Let the user select headers with the cursor keys, the same way they select
+messages in the main elm menu.
This is a good idea. It's slower than the current method, i.e. more than
one keystroke to get to the third through last headers, but more flexible
(doesn't depend on unique first letters for each header label).
+In fact, this could be combined with my earlier suggestion for passing the
+header info to the message editor. Just give the novices a message editor
+that strips out the headers, edits the message using their editor, and
+then goies into the elm header editor. Experts would just take this whole
+unit out of the loop.
One hitch with this is that some of the header lines would need to be
stripped out by ELM, altered and added back in. This would be the case
for 'to' and 'cc' lines where aliases would have to be replaced with
the associated real addresses. Also the 'bcc' line would have to be
stripped out altogether.
+What's more, it'd make the main program smaller.
Since the older way would still be in there for the novices, this isn't
so. Since we would have to add code to strip out and rewrite the headers
mentioned above, it would be that the code would grow, not shrink. But
let's not treat size as more important that functionality. (Then again,
if the program is too large to run, that *is* a matter of functionality. :-)
+ The downside is that you
+would have to replace huge sections of the header editor. And no, I'm not
+ready to do this myself. I'm still trying to get elm to work on Xenix 286.
The work involved in making this change (putting the header lines in
with the message body for editing together) is large enough that
probably none of the ELM developers have time for it. I myself have
been making roughly 70% of the bug fixes and changes provided by the
ELM development group and I've been spending about 20 hours per week
*of my own time* on ELM. And this is more to just get rid of bugs and
inconsistencies, rather than make bona fide enhancements.
--
Rob Bernardo, Pacific Bell UNIX/C Reusable Code Library
Email: ...![backbone]!pacbell!pbhyf!rob OR rob@pbhyf.PacBell.COM
Office: (415) 823-2417 Room 4E750A, San Ramon Valley Administrative Center
Residence: (415) 827-4301 R Bar JB, Concord, Californiapeter@ficc.uu.net (Peter da Silva) (12/23/88)
In article <4421@pbhyf.PacBell.COM>, rob@pbhyf.PacBell.COM (Rob Bernardo) writes: > In article <2510@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: > +What's more, it'd make the main program smaller. > Since the older way would still be in there for the novices, this isn't > so. Not so. I was suggesting making the whole message editor a seperate program, and providing a novice version that included the header editor. Novice: ELM -> msgedit -> their editor -> msgedit(header mode) -> ELM Expert: ELM -> editor -> ELM Oh well, I might go back to my original plan of abandoning ELM altogether and implementing VMAIL. I put that on the back burner when ELM was supposed to run on Xenix/286 in the next release. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Work: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. `-_-' Home: bigtex!texbell!sugar!peter, peter@sugar.uu.net. 'U` Opinions may not represent the policies of FICC or the Xenix Support group.
steve@raspail.UUCP (Steve Schonberger) (12/24/88)
In article <4417@pbhyf.PacBell.COM>, rob@pbhyf.PacBell.COM (Rob Bernardo) writes: > Randy, I think you missed the overall point. "Beneath" the discussion > of how to edit the headers was a discussion of introducing a new > header "Return-Receipt-To:". Well, the reason I suggested making Return-Receipt-To: a header just bit me tonight. I posted an article to a rather large mailing list, with Return-Receipt-To: uunet!rosevax!raspail!steve in my elmheaders file (my thanks to those who told me about that), and when I signed on and went into elm, it told me "Mailbox is [...], with 151 messages". I knew better, but got caught anyway. *sigh* Steve Schonberger steve@raspail.uucp raspail!steve@shamash.cdc.com ...!uunet!rosevax!shamash!rapail!steve