[comp.mail.elm] Patches and new functions

woerz%isaak@isaak.uucp (Dieter Woerz) (07/23/89)

In article <621@ispi.UUCP> jbayer@ispi.UUCP (Jonathan Bayer) writes:
>In article <581@tiamat.fsc.com> jim@tiamat.fsc.com (Jim O'Connor) writes:
>	[deleted]
>>[A way of changing the signature in a menu called from the send-
>> menu is bein described]
>
>OK.  I have been sitting back and watching, but now I think I will
>comment on this signature problem.
>
>Of all the suggestions that have come up, this is one of the better
>ones.  However, it doesn't take into account the problem of a mailing
>list.  If you have a mailing list of both local and remote addresses
>then either some of them will receive the wrong signature, or the user
>will be prompted for each address on the mailing list.  If you make the
>stipulation that the selection is applied to EVERY address on the list,
>then this method should satisfy most people.

I don't think there is a method for mailing lists. When you send mail
to a mailing list, it's like a broadcast, you don't address a
specific person. If the mailing list is evaluated by the MTA (e.g.
sendmail alias) you can't have this feature anyway. Why include it
into elm?

>[Some other stuff about making the above mentioned feature
> configurable deleted]
> ...
>[Personel comments about the ongoing development and the implications
> of new and wanted/unwanted/controversal features deleted]

I second the proposal, that there should be #defines for the
introduced features, so that they are configurable. So, in the above
mentioned case, someone who didn't wanted to have this feature,
simply put an #undef <feature> in his config file and had the old
behaviour again.

The names of features could be the something like Patch-level-
Corrected-Error-whithin-patch or the number the error (or feature)
has been assigned in the monthly posting.

If a new feature depends on an other one, there should be a warning,
that feature y also enables feature x, so that every "elm-builder",
knows this fact and can keep feature y disabled, if she/he doesn't
like feature x.

Dieter Woerz
ISA GmbH, Azenbergstr. 35 D-7000 Stuttgart-1 W-Germany
UUCP:           {pyramid!iaoobel,uunet!unido}!isaak!woerz
BITNET/EARN:    woerz@ds0iff5