Re: [Nmh-workers] Future directions for nmh

[Ken Hornstein]

>As you might guess if you've been on this mailing list forever, I'd
>really like to see a better user interface for reading attachments.
>In short, I'd like to keep track of the "current part", and have
>"next part" and "previous part" options to show.  There should be
>a flag that allows switching to the next/prev message if next/prev part
>runs out of parts.  To me, this would be so much better than having to
>do a mhlist and then type part numbers.  I looked at doing this years
>ago and got stopped by dealing with the parsing stuff.  There should
>also be an option to scan that lists the parts in messages.  So if the
>parser is redone maybe it will be done in such a way to support this.

So I think those things would be possible.  The current thinking is that
the message parser would be 'lazy', in that any time a message is opened
you're going to get the complete headers, and then parse the body if you
ask for it via the API.  I'm not convinced 'scan' is the right tool to
list message parts; we'd have to think about how that would work.  I would
also caution you that to completely parse a message's MIME structure you
need to read the whole thing; maybe this wouldn't be so bad on IMAP since
you could simply ask the IMAP server for the message's MIME structure
(hopefully once it built the structure it would be cached on the server).
My point is that you had a scan format that showed MIME structure, the
performance would probably be significantly impacted.

But I have to ask about the idea of going from one MIME part to another;
do you really want to do that?  I can only go on how I interact with
messages; almost always, I want to read the text part, and then interact
in some other way with non-text parts (generally save them or open them
with another tool).  'Stepping' through MIME parts is just not something
that makes sense to me.  Sure, I want to make it as flexible as possible
and just because something doesn't make sense to me doesn't mean it shouldn't
be possible!  But I do want to understand the usage case completely.  It
occurs to me that if we do it right we could make it easy to accomplish
this via scripts, which strikes me as more of the 'MH way' (basically,
provide the tools to interrogate the MIME structure of a message and then
go to the "next" MIME part).

>I am emboldened by David's posting regarding add-hook, etc.  Didn't know
>that anybody actually used that stuff other than me.  The hook stuff was
>an expedient hack on my part, and it's not really as robust as it could
>be.  I would like to see it made more of an integral part of nmh as
>opposed to the add-on hack that I did.

Well ... do you have any thoughts there?  I mean, seems like it's integrated
pretty well now.  Probably the two things that are lacking is a man page
and tests for the test suite (more people might know about it if the
various commands had pointers saying which hooks were invoked).

The bottom line is that all of this is a large amount to bite off at once.
My first thought is to do the MIME parser, but keep the rest of everything
as close to the same as possible.  Then we can talk about different mailstores

--Ken