Re: [Mutt] #2995: Mutt is folding subject line folds using a tab,
Hi,
* Derek Martin wrote:
> Actually, taking another look at this, I don't understand why this
> function exists at all... As far as I can tell, there are no
> circumstances under which a header should *ever* contain any
> characters other than 7-bit ASCII. RFC (2)822 clearly states so, and
> the only other standard I'm aware of related to the formatting of
> headers is RFC 2047, allowing for encoded words to represent non-ASCII
> character sets; however even here, the non-ASCII characters MUST be
> encoded using only 7-bit ASCII.
Indeed, this function gets called with every header mutt produces... be
it for display or for outgoing messages. It's only purpose is to wrap
overly long header lines but leave everything as-is (i.e. honor
preformatted headers). In particular, there's no prior unfolding taking
place.
> The only time this shouldn't be true, as far as I can tell, is when
> mutt is actually displaying the header to the user, who quite
> naturally shouldn't be expected to be able to parse RFC-2047 encoded
> words in his head. But the decoded header should only ever exist in
> memory for purposes of display; Mutt should never write it out
> decoded anywhere else.
The builtin pager displays tempfiles only so the decoded header is
written out to the tempfile.
> I suspect the fundamental problem is that whoever wrote this wanted it
> to be used both for writing the headers when sending the message, and
> also when displaying it... and probably that's the Wrong Thing(tm),
> since those two operations are inherently very different. But I would
> need to dig into this much more than I had time for.
Well, I don't think it's that wrong. Sure, these are different
operations but breaking long header lines is basically the same so both
share the same code (well, except that for readability on display we
want to fold with tab).
Rocco