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. Jon _______________________________________________ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
