Re: [Nmh-workers] Future directions for nmh

2016-03-11 Thread Paul Vixie
Ken Hornstein wrote: 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. But ... what's wrong with doing something like: mhstore -type image Then you can

Re: [Nmh-workers] Future directions for nmh

2016-03-11 Thread Ken Hornstein
>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. But ... what's wrong with doing something like: mhstore -type image Then you can deal with each of those

Re: [Nmh-workers] [PATCH] Add pick -reverse switch to print reversed output

2016-03-11 Thread Ken Hornstein
>If this passes muster, would someone else mind submitting? Done! Thanks! --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Future directions for nmh

2016-03-11 Thread Ken Hornstein
>Rather than push the mailstore code into MH, I think a much cleaner >model would be to use FUSE-based providers that translate between >external store formats and the native MH layout. This means no >intrusive changes to MH itself, and people can roll whatever >translators they want. There was

[Nmh-workers] [PATCH] Add pick -reverse switch to print reversed output

2016-03-11 Thread epg
Just a little something I've had in my local branch for some 15 years :) Rediscovered that I never submitted it when I was checking that the xoauth branch still works (clean merge, btw, except one little Makefile.am conflict). If this passes muster, would someone else mind submitting? I

Re: [Nmh-workers] Future directions for nmh

2016-03-11 Thread Lyndon Nerenberg
> On Mar 11, 2016, at 11:01 AM, Paul Vixie wrote: > > my situation is the opposite. i'd like multiple mail store types inside NMH, > or a pluggable hooks-style interface allowing the creation of same, so that i > can use NMH command line tools to attack my Maildir store as

Re: [Nmh-workers] Future directions for nmh

2016-03-11 Thread Jon Steinhart
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

Re: [Nmh-workers] Future directions for nmh

2016-03-11 Thread 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

Re: [Nmh-workers] Future directions for nmh

2016-03-11 Thread Laura Creighton
I'd just like to mention that I am still getting lots of use out of the mh mail storage. A lot of the mail that I receive is code checkins. Perhaps when everybody on the planet has moved all of their code to github (as seems to be happening whenever I turn around) I won't need my tools to find

Re: [Nmh-workers] Future directions for nmh

2016-03-11 Thread Paul Vixie
Ken Hornstein wrote: i believe that the gnu team has an MH-like tool set that's designed this way. if so then we might just tell people like me to go use that. If you're talking about GNU mailutils, then yes. I mean, it does include a MH-compatibility layer and works with IMAP; I do not

Re: [Nmh-workers] Future directions for nmh

2016-03-11 Thread Ken Hornstein
>i believe that the gnu team has an MH-like tool set that's designed this >way. if so then we might just tell people like me to go use that. If you're talking about GNU mailutils, then yes. I mean, it does include a MH-compatibility layer and works with IMAP; I do not know how full-featured it

Re: [Nmh-workers] Future directions for nmh

2016-03-11 Thread Paul Vixie
Jon Steinhart wrote: OK. That's a really cool idea. One could even contemplate using gmail as a mail store to make it easier for the NSA to read your mail. Maybe the hooks should be replaced by one of the DLLs. This sounds like a huge change in the codebase, so hopefully someone is up for

Re: [Nmh-workers] Future directions for nmh

2016-03-11 Thread Jon Steinhart
Ken Hornstein writes: > >All of the email about which I care has ASCII subject lines. > >Also, I often grep for a particular attachment name. > > Right or wrong, I get subject lines that are encoded using RFC 2047 > rules. I know you think of those as 'foreign languages', but that is > wrong;

Re: [Nmh-workers] Future directions for nmh

2016-03-11 Thread Ken Hornstein
>OK. That's a really cool idea. One could even contemplate using gmail as a >mail store to make it easier for the NSA to read your mail. Maybe the hooks >should be replaced by one of the DLLs. This sounds like a huge change in >the codebase, so hopefully someone is up for it. Being

Re: [Nmh-workers] Future directions for nmh

2016-03-11 Thread Jon Steinhart
Paul Vixie writes: > > Jon Steinhart wrote: > > ... > > Are you saying that you'd like to see the nmh cli abstracted to the point > > where it could work on different flavors of mail store? If so, that seems > > like a big change. Sort of like the hooks, but with a DLL interface > > instead of

Re: [Nmh-workers] Future directions for nmh

2016-03-11 Thread Paul Vixie
Jon Steinhart wrote: ... Are you saying that you'd like to see the nmh cli abstracted to the point where it could work on different flavors of mail store? If so, that seems like a big change. Sort of like the hooks, but with a DLL interface instead of the shell? yes. -- P Vixie

Re: [Nmh-workers] Future directions for nmh

2016-03-11 Thread Ken Hornstein
>All of the email about which I care has ASCII subject lines. >Also, I often grep for a particular attachment name. Right or wrong, I get subject lines that are encoded using RFC 2047 rules. I know you think of those as 'foreign languages', but that is wrong; they are just 'characters'. Also,

Re: [Nmh-workers] Future directions for nmh

2016-03-11 Thread Jon Steinhart
Paul Vixie writes: > Jon Steinhart wrote: > > ... > > 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. > > useful for what? i have no remaining use cases of my own. All

Re: [Nmh-workers] Future directions for nmh

2016-03-11 Thread Paul Vixie
Jon Steinhart wrote: ... 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. useful for what? i have no remaining use cases of my own. I am emboldened by David's posting

Re: [Nmh-workers] Maybe time for a new release?

2016-03-11 Thread David Levine
Norm wrote: > I want to output to stdout all the lines of that part that contain the > string "family". What command go I feed into 'grep family"? Well, it depends whether you want to modify the message on disk or not. If you do want to modify the message permanently: $ mhfixmsg $

Re: [Nmh-workers] Future directions for nmh

2016-03-11 Thread Jon Steinhart
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

Re: [Nmh-workers] Maybe time for a new release?

2016-03-11 Thread Ken Hornstein
>I am terribly sorry to be so dense, but none of your examples do it for >me. Suppose that I know that the current message in the current folder >has a part which is either utf-8 or a quotedPrintable and that >I want to output to stdout all the lines of that part that contain the >string

Re: [Nmh-workers] Maybe time for a new release?

2016-03-11 Thread norm
David Levine writes: >Norm wrote: > >> The bulk of the non-spam mail I receive still has a utf-8 or a >> quotedPrintabl e part. I would like to apply UNIX text processing tools >> (grep, wc, sort, uniq, perl, etc) to these messages. It would be nice if the >> next release