I believe the mhl configuration file is sufficiently expandable enough so
that we can continue to use it as-is. Although .... I guess my question to
you would be, if we had a new mhl-like program that was MIME-aware, why would
you want to keep the old mhl around?
mhl has baggage that I don't believe that -- nor do I believe that you believe
-- the new program (call it mhmime) should have. Examples are the output and
terminal related stuff, -bell, -clear, -length, -width, -moreproc, which have
nothing to do with parsing mime stuff.
I can't argue that (-bell is clearly the biggest offender), but consider
the flip side ... someone has to write that new program from scratch.
It might be easier to simply rototill mhl to add the new features. Also,
I believe -length and -width might be useful if you wanted to override the
default terminal size (although if you're deprecating -clear and -bell,
you don't need -length, I believe). Our hypothetical new mhl program
would still use a pager, so you'd still need -moreproc.
The same goes for, show, mhshow, next and prev. They should go into nmh-1.7
pretty much as is, but deprecated, and be absent from nmh-1.8.
Hm, that's not what I was thinking. I was thinking show, next, and prev
would still stick around (they wouldn't even change that much). They'd
get some new switches that mhshow had (and presumably pass them down to
mhl). mhshow would just become show.
--Ken
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers