My feeling is that using %(trim) is addressing the symptoms of the
original bug rather than the cause: %{subject} shouldn't be appending
blank spaces to the original message subject. Also, as most Nmh user's
have their own customised replcomps file, adding trim to the one
distributed with Nmh, wouldn't fix the original problem.
I understand where you're coming from, and I can even agree with it, but
I'm thinking that we should look for a different implementation somehow.
Like I said, all the solutions are complicated.
I'm not sure I've understood what the old change of mine broke. Have you
got an example header? Is it related to wrapping lists of addresses?
Sure (and yes, but it actually affects all line wrapping).
Create a message with multiple cc: lines, one address per line.
E.g.:
cc: user1(_at_)example(_dot_)com
cc: user2(_at_)example(_dot_)com
Now this is in the violation of the RFCs, but let's put that aside
for now. Try replying to it; what happens is you end up in the reply
with this:
cc: user1(_at_)example(_dot_)com user2(_at_)example(_dot_)com
Which throws an error (you can still reply, you'll just get a warning
in the reply message).
The code after line 172 of replsbr.c is designed to handle the case where
you get multiple components in the same file. It uses the newline at the
end of the saved component as an indicator to how we should perform
line wrapping. If it's tagged as an address componet, it should
get wrapped as:
user1(_at_)example(_dot_)com,\n\tuser(_at_)example(_dot_)com
If it's NOT an address component, what should happen is that it
gets wrapped on a new line with a \t. But with your change this
doesn't happen.
This only affects messages with multiple components with the same name.
Again, these messages are sort of bogus (although I guess you can have
multiple Resent-From: headers), but I think it's reasonable to deal with
them, especially since nmh has a history of doing that AND that keeps
with Postel's law.
But of course the other half of Postel's law is that we should be
conservative in what we send. I guess from the bug report there were
problems with blank spaces at the end of particular headers? Okay,
I can understand that we shouldn't do that; it's kinda bogus that other
mailers have problems with that, but it's still wrong of nmh to add spaces
where there weren't any before. So how do we solve this?
Once again, that damn m_getfld() comes back to bite us. We can't
be guaranteed that every call to m_getfld() returns a complete line
(at least that's my reading of it, but I could be wrong about that).
A (simple) solution that occurs to me is this: if there is a newline
at the end of a component, we could simply get rid of that in fmt_scan.
Specifically when an FT_COMP or FT_COMPF instruction copies the component
into the str register. Thoughts?
--Ken
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers