I have a wishlist for things I'd like to see in an ideal mhn/mhbuild.
Some of these are pretty straightforward, and fit reasonably in the
current mhn model. Others are more ambitious or don't quite fit in
the current model, and I'm hoping that someone will come up with some
way of doing them that does.
This is just to spur discussion, and comments from Richard about
where he wants to go. I'm willing to do some of the work when
mhn/mhbuild reach a point Richard thinks is stable enough for that (I
know he was/is doing some major re-org of this stuff, and it would be
unwise to start any other changes in parallel).
So, in no particular order:
- Specifiable encodings for mhbuild, as has already been discussed.
- Handling of unknown content-transfer-encodings via external
programs in $MHN (for both mhn and mhbuild).
- Handling of unknown access-types for message/external-body, or at
least handling of the RFC 2017 "URL" access type (presumably by
external program; building HTTP, gopher, and maybe wais clients
into mhn seems a bit much).
- Preferences for multipart/alternative. For example, I prefer
text/plain over text/html (or almost anything, really) in a
multipart/alternative, but I want to be able to show text/html if
that's all there is.
- Handling of Content-Disposition (RFC 2183). For mhn -store, I'd
like to see it use the "filename" (or at least the basename of the
filename) as the default output file), and for mhn -show, I'd like
this name to be available as a % substitution to show procedures in
the $MHN file. I don't know if the inline vs. attachment notion
makes a difference in the context of MH, though it might in
conjuction with my next far-fetched wish:
- Some way to display consecutive inline parts (including the orignal
headers) as a single entity. For instance, if I have a message
with two text/plain parts (that are inline unless Content-
Disposition says otherwise), I'd like to be able to get the headers
and the two parts into a single invocation of "less". Or even if
one of the parts is text/enriched, I just pipe it through a simple
converter and into less now; it would be nice if this could just be
`merged' with surrounding things that also get piped to less. This
is probably the biggest single thing pushing me towards regularly
using some sort of GUI mailer (probably exmh) even though I prefer
the commandline style, but I don't even know how one could express
this sort of thing in the $MHN file, let alone implement it.
- For both show and composition, better access to other parts within
a multipart. For example, with the multipart/signed PGP/MIME type,
you can't really show or compose such a beast very well. On the
show side, you can have a script for multipart/signed, but since
the signature is on the encoded other part with headers, and mhn
only hands you a decoded, headerless file, you can't check the
signature yourself. You can't even go to the whole original mail
message directly, because you don't get a way to get that, either;
you can hope it's the 'cur' message in the current folder, but that
may not be true (given mhn -file). For composition, you have a
similar problem; the signature needs to be generated over another
part in the multipart. Again, I have not come up with a good way
of going about this.
- Content-Id as a % substitution.
- For mhbuild #forw, somehow specifying a filter file for the
forwarded message(s), either on the command line, in the directive,
or the .mh_profile or $MHN file. In the directive would be most
flexible, but I could live with any of the others.
- Some way of controlling quoting of % substitutions (at least the
ones with content that nmh does not generate). For instance, if I
use "mhn-show-text/x-whatever: someprog '%F' '%d'" and the Content-
Description has a ' character, bad things could happen. Consider
the above with something like:
Content-Description: sucker!' | rm -rf / ; echo 'so long!
But if I don't use '%d' it is worse because even simpler things
will screw up. Perhaps they should just always be expanded with
included single quotes, with any single quotes appropriately
quoted? For example, given the above, %d would be expanded to:
'sucker!'\'' | rm -rf / ; echo '\''so long!'
This (I believe) does the right thing with all shells, but breaks
if the user is already using '%d' instead of just %d. :-(
- As a minor nit, and related to the example in the above one,
because mhn puts an "exec" in front of the shell command, entries
like "mhn-show-text/x-whatever: something ; something_else" do not
work as expected (which is why I had to use "|" above). I'm not
sure why the "exec" is there; it saves a process, but causes this
particular confusion. Not a good tradeoff, IMHO.