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(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers