>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: [email protected] cc: [email protected] 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: [email protected] [email protected] 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: [email protected],\n\[email protected] 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 [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
