rob@pbhyf.PacBell.COM (Rob Bernardo) (12/28/88)
In article <1324@vsi1.COM> lmb@vicom.COM (Larry Blair) writes:
+I don't see why the "From To:" syntax was chosen for this purpose. A
+much simpler solution is to display the "To:" name whenever the "From:"
+name is the user. This is the solution used by "mush".
This was one of the very first enhancements implemented in the development
of ELM 2. (Since enhancements were not allowed in ELM 2.1, you'll see
this feature in ELM 2.2.) In fact a number of changes regarding From and To.
1. As above, instead of doing a weird From line in the saved copy of
your outbound message, the copy is saved with all headers as in the
outbound message, plus Bcc. For the purposes of display, ELM shows
the To instead of the From when the To is the user.
2. When the To is the user, when saving a message to a file, the
save-by-name option causes the logname of the From to be used in
formulating the file name rather than the logname of the To. (This
helps ensure that correspondence to and from and individual will be in
the same save file, and is consistent with the automatic save-by-name
option in the elmrc.)
3. When creating an alias for the current message, if the To is the user,
the address of the From is used instead of the address of the To. This allows
you to create an alias for someone, even if you only have a message you
sent. It saves you having to manually formulate and enter the address.
+Btw, I think you should be able to suppress the "Press return to return to
+elm" at the end of viewing a piece of mail. I use "less", which provides
+the marvelous ability to go backwards at the end, rather than falling out
+like "more". This ends up meaning that I have to either type an extra
+<cr>, or give up the ability to go backwards.
I sometimes use less to, and I think this is a fantastic idea. I'll implement
it in ELM 2.2.
+I just started using elm, so I'm not aware of who does what here. Are
+all new features "Do it yourself if you want it", or are there one or
+two serious elm hackers that like to do these kinds of enhancements?
Well I'd normally let our ELM coordinator answer a question like this,
but since I'm here ...
ELM is officially in the hands of an all-volunteer development group
organized a ways back in this very news group. Syd Weinstein <syd@dsinc>
is the coordinator for this effort. The developers (I'd say that there
are about a half a dozen ones who regularly submit changes and a dozen others
who regularly call attention to bugs and offer opinions on proposed
changes.) ELM 2.1 was our initial effort, largely chaotic under another
coordinator. We are currently working quite organizedly on ELM 2.2.
We submit patches to Syd who then changes the official ELM code,
kept under version control and issues back an official patch to the developers.
Syd does some checking (although he can better tell you about this), but
if one developer's patch does something untoward to ELM, you can be
sure that the other developers will catch it and help correct it. Development
of ELM 2.2 will come to a close shortly (don't have the schedule in front
of me) after that it will be tested (and only bug fixes will be accepted
from the development group), and then shortly after that it will be released.
I think that will be towards the middle or end of 1Q89.
+If I do make the enhancements, is the a patch repository that would
+be interested?
The following is my opinion and I can't claim to speak for the entire
development group: Let's make a distinction between
1. bug fixes (ELM doesn't do what it was intended to do) and
"changes" (ELM doesn't do something that would be an obvious
improvement and the change is in keeping with ELM's style
and the change is not extensive or controversial.)
2. "enhancements" (A change that is either extensive, introduces
a new style or feature to ELM, OR may be controversial.)
(For example, your suggestion about an option to avoid the prompt and
keystroke after the external pager is done fits into the #1 area,
not the #2 area.)
By all means call our atttention to #1, either in this group or by
writing directly to Syd Weinstein <syd@dsinc>. If you have a patch
or even less formal description of how to fix the bug, let us have
that as well. We will try to implement the bug fix in ELM 2.2.
But as a change nears that of type #2, I'd rather the issue be merely
brought up for discussion, again either in this group or by writing to
Syd. This allows the "serious" developers who are quite familiar with
(parts of) the ELM code to consider the change from an internal (code)
point of view as well as from an external (user) point of view.
--
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