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
>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
>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
>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
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
> 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
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
>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
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
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
>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
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
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;
>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
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
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
>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,
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
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
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
$
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
>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
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
23 matches
Mail list logo