Howdy. I want to start by thanking those of you who actually have time to work on this. Wish that I had some time to spare. Here's my grumpy-don't-break-things opinion.
I support redoing the email parser and making everything MIME-aware. 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. I think that we should keep the mail store as is. I agree that the MIME and character set stuff has made it less grep-able than it used to be, but it's still useful. 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. The reason that having a solid hooks implementation is important is that it allows users to have whatever alternate mail stores suit them without having to make them part of nmh. The way that I manage my mail here is to have hooks that mirror my mail folders in ElasticSearch. I have some additional commands (gpick/gscan) that work just like pick/scan but are very fast by comparison. I wrote a mail parser years ago that makes this work. It's pretty out of date now. It has a feature that would be nice to support, which is that it allows (in a manner similar to stuff in mh_profile) external helper programs to be specified so that text can be extracted from non-ASCII attachments. For example, it can pipe a PDF attachment through pdftotext. It also has the ability to control what header fields get indexed. So I guess my opinion is that improving the parser is a great thing, and improving the way that external stuff can work with nmh is preferable to changing the way that nmh works as far as mail directories, etc. And, of course, I'd like a better ui for part handling. Jon _______________________________________________ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers