[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] Features for 1.6

From: Jeffrey Honig
Subject: Re: [Nmh-workers] Features for 1.6
Date: Wed, 16 Oct 2013 22:02:11 -0400

One problem we have run into with mh-e and nmh 1.5 is that mh-e is no
longer able to read the comp formfile directly.  That's because of
some dynamically generated content, isn't it?

Right now we are changing the code to use comp to generate a draft and
then reading that in.  That requires creating a temporary directory
and running comp there.  That insures that we can read message 1.

What can we do to simplify this? The obvious answer would be to add a
-build flag to comp as is supported on repl and forw.


Jeffrey C. Honig <address@hidden>
GnuPG ID:14E29E13 <http://www.honig.net/jch/key.shtml>

On Wed, Oct 16, 2013 at 3:24 PM, Ken Hornstein <address@hidden> wrote:
> So it's been more than a year since the 1.5 release ... and I'm thinking
> it's time to start working on 1.6.  I think that 1.5 holds up pretty
> well so I'm not itching to get 1.6 out of the door right now, but there
> is some cool stuff in the master branch that would be nice to get out
> there.  But I still want to get some things in there, so here's what I
> was thinking about getting working for 1.6.
> - Support character set conversion for mhshow(1) using iconv
> - Adapt meillo's changes to mhshow(1) so each MIME part doesn't use their
>   own pager.
> - Maybe make mhshow(1) the default instead of show(1).
> - Always run mhbuild on outgoing drafts.
> - Have mhbuild handle RFC-2047 encoding
> - Support RFC 2231 MIME extended parameter encoding and decoding
> And to borrow a management term, some "stretch" goals are:
> - Support the composition and display of format=flowed messages.
> - Add encryption/decryption support via external programs (like openssl,
>   gpg, etc).
> - Design a proper MIME multiplexing architecture that can handle things like
>   having repl decide which MIME parts to select from a message to include in
>   a reply.  Maybe via mhl?
> Anything else that strikes people's fancy?  Obviously preference will be
> given to items that include coding resources :-)
> --Ken
> _______________________________________________
> Nmh-workers mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/nmh-workers

reply via email to

[Prev in Thread] Current Thread [Next in Thread]