Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!sdd.hp.com!news.cs.indiana.edu!ux1.cso.uiuc.edu!midway!clout!chinet!les
From: les@chinet.chi.il.us (Leslie Mikesell)
Newsgroups: comp.mail.elm
Subject: Re: Hey Syd, here's a couple of ideas!
Message-ID: <1991Jun21.035847.18287@chinet.chi.il.us>
Date: 21 Jun 91 03:58:47 GMT
References: <1991Jun20.044510.781@osh3.OSHA.GOV> <1991Jun20.141539.16160@DSI.COM>
Organization: Chinet - Chicago Public Access UNIX
Lines: 50

In article <1991Jun20.141539.16160@DSI.COM> syd@DSI.COM writes:
>>Another complaint is no binary attachments.
>This one has been under discussion since 2.2 was being developed.  We
>even, internally, floated a proposal about it.  No one did anything
>with it, partly because the AT&T method, Content-Type:/Content-Length:
>for attachments didn't go anywhere and become a 'global' standard,
>and at that time, not too much need, compared to now.  Plus, at that
>time, most mail transports were not 8 bit clean, so the best
>we could do would be a uuencoded attachment....

>Now, the IAB is just starting the process of standardizing an attachment
>interface/headers.  That work is going to take a while until the standard
>becomes published.  I would like Elm 3.0 to honor that standard (and
>perhaps also the older AT&T one), but I think it will come out too late
>for use in 2.4.

SysVr4 mail has the Content-Type:/Content-Length: headers and doesn't
escape lines starting with From in the body.  It's likely that there
will be a fairly large installed base of these around very soon.
How about working in at least a tolerance for these messages in the
next release?  At the very least, don't look for the start of a new
message within the bounds of a Content-Length: header, add a command
to save the body only which respects the Content-Length: header
(multi-part support would be nice, but just getting the entire multi-part
chunk into its own file would be a start), and don't barf when you
hit NULLs in the body of a message.  Actually I think the performace
gain of doing the initial read/copy of the mailbox with large
read()s and parsing the lines yourself would be worth the trouble
compared to the current fgets(), even aside from the fact that it
would work in the presence of nulls.

>>Another thing I have yet to see is a macro language or API for Elm. 
>I need some convincing here that an Elm macro language would really
>do something and buy you something....   As for API, I am unsure
>how that would be used.... I need some 'education' there.

Maybe you should ask in the mush group whether macros and a script
language are useful, since those people would have the most experience
with them.  I think simple macros would be nice but I prefer elm
to mush because you can give most of the commands from within the
built-in pager.  I normally can't tell enough about a message to do
anything predictable without seeing at least the first screen.  One
other thing that I would find very useful would be a way to add and
edit headers when both sending and reading mail.  For example, it
would be nice to be able to add a Keywords: header on received
messages or edit the Subject: line.  Then a command like mush's "pick"
would become useful, where it typically isn't on the mail I receive.

Les Mikesell
  les@chinet.chi.il.us