Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!psuvax1!psuvm!VIRGINIA!JBB From: JBB@VIRGINIA.BITNET (Joseph B Burch Academic Computing) Newsgroups: bit.listserv.mailbook Subject: Re: BSMTP header Message-ID: Date: 2 Feb 90 22:51:35 GMT Sender: MAIL/MAILBOOK subscription list Reply-To: MAIL/MAILBOOK subscription list Lines: 40 Approved: NETNEWS@PSUVM Gateway In-Reply-To: Message of Fri, 2 Feb 90 15:22:06 CST from said: >Frankly, I agree. But to be perfectly honest, I've just not had the time >to do that kind of work. And it will be a fairly substantial amount of >work, by the way. > Sorry to have started a food fight, Richard! How about just disallowing cursor positioning in the header area for the time being. This should keep most folks happy... >I think we can avoid too much of this by saying that this is a future >objective. I will warn you of one thing, however: it's going to >cost you something, because it means that the code will have to do >a bunch of extra scanning of the header lines to make this work. > >Which would you prefer: when the user types over the header lines and >produces something unparseable, > >1. Notice the problem at that point (which means you have to scan the > header lines *every* time a change is made) >2. Notice the problem only when you try to send the message (which means > that the user won't be told when he or she makes the change but > presumably quite a while afterwards, but does limit the amount of time > spent scanning the header lines) > 3. Scan the header lines only after the cursor has first been moved into the header area and then a) moved away or b) a PF key has been struck. >It occurs to me that maybe we're really barking up an entirely wrong >tree here. Do we really want to have to depend on people entering >the exact syntax of an RFC822 address by hand? (Don't forget to >put double quotes around the name if certain characters are in it; >remember to put those funny angle bracket things in the right places, etc.) >Maybe what we really need is a completely different way of looking at >the entire problem that allows full-screen changes, sure, but in >a less syntactically painful way. This will require a lot of thought >to do right, but I'm not going to expend a lot of effort on manually >updating header lines if I can think of a different, but better way >of doing the same thing. > Sounds good to me, Richard. Thanks for your feedback ... Joe