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).
Here is a coredump of the various ideas I have floating around.
As John said, the code in mhn/mhbuild is being reorganized at the
moment, so there is no timetable on the implementation of any of
these ideas.
- 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).
I'm still pondering the transfer encoding situation.
- 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).
This is probably not too hard. I haven't done much work on the code
for message/external, but since we already have the ability to use
an external program for ftp, extending this to http shouldn't be
too hard.
- 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.
Some of this code was just fixed in the last release. Now, a
text/html part inside a multipart/alternative will only be shown
if there is a profile-entry for it. The default behavior (display
unknown subtypes of text as text/plain) will only be used if it is
NOT part of a multipart/alternative.
- 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:
Handling Content-Disposition is on my short term TODO list (as least
for filenames).
- 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.
I've also been pondering similar ideas. And surprisingly, I don't
think it will be too hard to do this (at least in the simple cases).
But first, I plan to add the ability to merge the display of header
fields with the display of a single content. The eventual goal is
to merge "show" and "mhn -show". One of the reasons that displaying
MIME messages is slow, is that "show" first scans the message to
find out it is MIME and execs mhn. Then "mhn" scans the message
and parses the various contents, and thens it execs a separate
program for the headers, as well as each content.
- 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.
This is harder. I'll have to think about this.
- Content-Id as a % substitution.
I'll look into this.
- 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.
I've also been thinking about this. I would like to allow each
directive to be able to specify a post-compostion command. These
will allow you to filter text included directly in the composition
draft, as well as included via directives such as:
1) #forw
2) #text/plain filename
3) #<text/plain
- 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. :-(
Hmm... quoting rules always suck. Don't they. I'll also need
to ponder this.
--
Richard Coleman
coleman(_at_)math(_dot_)gatech(_dot_)edu