Ken Hornstein <k...@pobox.com> writes: (10 weeks ago) >So, here's my thinking. Traditionally, the job of actually DISPLAYING >messages has been done by mhl. It seems to make sense that instead of >having two utilities (show and mhshow), there be only one utility: show, >which really uses mhl for it's heavy lifting. > >Mhl already has a facility where you can give it information on what >exactly you want to display. It would make sense to expand this to >encompass various MIME parts. Here are some sample mhl format file >lines, which I've just shot from the hip and haven't thought about them >too much: > >body:match,ct=text/plain,inline,ctparam{format}="flowed":display,flowed >body:match,ct=text/plain,inline:display >body:match,attachment:marker="Part %{part} %{content-type}" > >This would let you specify seperate mhl file for replies, and could make >use of existing infrastructure in repl. > >Like I said, I haven't thought about this TOO much. But that's the >general idea.
So, ALL nmh responsibility for parsing and extracting mime parts would be in [what mhl would become]. None would be in show, mhshow, repl, or anywhere else Correct? You didn't say so, but I take it that the results of the new program, would also be available for other, user created, purposes. I like the basic idea. I like it a lot. But the new mhl would be sufficiently different that it should have a new name, to avoid backward compatibility constraints. "Write programs that do one thing and do it well." http://en.wikipedia.org/wiki/Unix_philosophy. I urge the community to explicate Ken's general idea. Norman Shapiro _______________________________________________ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers