Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!wuarchive!psuvax1!psuvm!UTORONTO!MICHAEL
From: MICHAEL@UTORONTO.BITNET (Michael Wagner)
Newsgroups: bit.listserv.mailbook
Subject: Re: BSMTP header
Message-ID: <MAILBOOK%90020212350069@UTORONTO.BITNET>
Date: 2 Feb 90 19:36:36 GMT
Sender: MAIL/MAILBOOK subscription list <MAILBOOK@RICEVM1>
Reply-To: MAIL/MAILBOOK subscription list <MAILBOOK@RICEVM1>
Lines: 38
Approved: NETNEWS@PSUVM Gateway
In-Reply-To:  Message of Thu, 1 Feb 90 11:58:31 EST from <JBB@VIRGINIA>

I don't understand something very fundamental about this discussion.
Why not accept the changes to the header elements as requests from a
naive user to change the header as he has? I.e., if MAIL/BOOK needs to
have the INCLUDE/EXCLUDE issued in order to have the changes reflected
in the BSMTP, why not issue them internally?

Typing over the header is the most obvious way for someone to change
something if they don't know much about the package (as is the case
for most new users). Why not gently steer them back into acceptable
usage by accepting the most obvious input?

Now, granted, the typed-over input may be invalid, but the logic to
determine that is already built-in to include/exclude. So if
include/exclude fails, the type-over logic could re-instate the old
header element.

In fact, the command orientation of the header, combined with the
full-screen orientation of the body, has always seemed odd to me. It
seems to me a worthy goal to make all the full-screen editing work in
the header as well, for those who even understand RFC822 headers. If
you delete the last line in a header element, the comma on the
previous line should disappear, and the header element should be
re-checked for correct syntax. If you delete a must-exist element, a
warning should occur, and you should be given the option of
re-instating the essential element. And so on. If one set of commands
(add line, delete line, etc) worked for both halves, there would be a
smaller learning curve.

Now, I know enough about the code to know that this is not a trivial
task, so I'm not suggesting that this should be undertaken overnight.
But I don't have a lot of sympathy for the sentiment, expressed
recently a lot on this list, of let the buggers freeze in hell if they
type over the headers rather than learning the extra handfull of
commands for manipulating the headers. It sounds pretty user-hostile
to me to adopt this sort of attitude. Besides, most header
manipulation I do can't be done with the supplied commands.

Michael