[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] Future directions for nmh

From: Jon Steinhart
Subject: Re: [Nmh-workers] Future directions for nmh
Date: Fri, 11 Mar 2016 17:36:54 -0800

Ken Hornstein writes:
> >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).

Well, it depends on the message.  Sometimes I get a message with 20 photos
attached.  I just want to be able to easily go from one to the next without
having to type their part number.
> >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).

There is no real error recovery.  I thought that I had added it to the man
pages but it was a long time ago and don't remember now.

> 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

I agree, I just would like to keep these other things in mind while doing the
parser so that they're not precluded later.

Gotta run, be back in touch on Monday.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]