[Top][All Lists]

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

Re: [Nmh-workers] repl*comps and and non-ascii characters

From: Peter Maydell
Subject: Re: [Nmh-workers] repl*comps and and non-ascii characters
Date: Sat, 26 Jul 2008 12:10:57 +0100

Eric Gillespie wrote:
>Peter Maydell writes:
>> Eric Gillespie wrote:
>> >+   * etc/replcomps, etc/replgroupcomps: Decode header fields for the
>> >+   reply's header.
>> If you do this then what causes them to get reencoded before sending?
>The same thing that encodes them when you compose a new message
>with such characters?  I use mh-e; maybe mhbuild handles it for
>plain nmh users?

As far as I am aware nothing currently does that encoding, which was
my point. (I guess mh-e has done some kind of workaround -- we should
probably find out what exactly it does so we don't break it when we
add proper support in nmh proper.)

You can't make replcomps decode the headers until there is something in
place which can do the reencoding. (And there are issues involving what
character set you're decoding to and what you do if it doesn't support
all the characters in the header.)

>> I agree that there are problems here but I think we need to solve them
>> in a more general manner (see the long message I posted a while back
>> about improving MIME support:
>> http://lists.gnu.org/archive/html/nmh-workers/2008-06/msg00003.html )
>OK, I guess.  Don't let the perfect be the enemy of the good :).

I am mostly concerned with
(a) not breaking the setups of existing nmh users (which this would
do, because suddenly a reply would go out with non-encoded headers
when previously it would not have done)
(b) not doing things which get in the way when we eventually do
a 'proper' solution to these things
(c) having it be clear how to configure nmh to do the 'right thing' --
remember that many people use their own tweaked copies of things like
replcomps files so merely changing the supplied defaults isn't sufficient:
if we have a 'this is the recommended config for MIME' setup then we
need clear documentation/release notes so everybody can update to it
(if they choose).

Adding decode() calls to replcomps etc is in the 'master plan' (see
part F1), but you can't just do it as a standalone thing.

-- PMM

reply via email to

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