Re: Getting RFC 2047 encoding right

> If the editor were internal the MUA could do 2047-decoding for display 
> purposes and keep the raw data as its basic storage. But since the 
> editor is external, the MUA must do 2047-decoding and hand the result 
> to the editor. Later, when the editor hands it back, the "obvious" way 
> is to 2047-encode the editor's result use it. Then there's only one 
> encoder to write and test, and it's used for original messages, for 
> forwarding and for replies. Less to write, less to test, fewer bugs.
if there's no good way to save state (like the original header fields) 
unchanged across that edit, so that the encoder has the ability to tell 
whether the human user changed those fields from those originally 
specified, then I can understand the difficulty.  If I were writing an 
MUA that used such an arrangement for editing header fields I'd try to 
find some way to save that state and make it available to the encoder - 
perhaps by using hidden fields that the human can't change, or by 
storing the original state in a parent process and having the editor 
run in a subprocess, or something.