>As I'm sure you'll recall :-), fmt_compile() calloc's a bunch of >struct format's, then fills some or all of them in. They're in >contiguous memory, not a linked list. We could look to see if >there's an unsed one at the end, and if so, copy the last one to it >and slip the new one in. If no room, we'd have to calloc n+1, copy >all, and insert.
Hm. I don't think we can figure out, without a lot of work, where to place an appropriate format instruction to include a Fcc. For example, on the stock replcomps you'd want to insert a Fcc _before_ the header separator line. And really, it could depend on how the format script gets interpreted. >And, there's the point that kre raised about users possibly depending >on the -form switch to disable or modify the fcc. They might not like >the warning, but it would be accurate. And their profile, components >files, scripts, etc., would still work. I'm trying to imagine why someone would specify both a -fcc switch and a -form switch to ignore a -fcc. I mean ... yes, that is possible. More likely I think is a person had a replcomps they had from a few decades ago that they deleted the Fcc: line, and they complain when the -fcc switch doesn't work because they don't understand the linkage between those switches and the various components files. If the goal is to really ignore a -fcc switch maybe you had in your profile, we could always provide a -nofcc switch. A warning message could mention that -nofcc is an option. It just seems to me that -fcc that doesn't actually do anything implies a misconfiguration, but it's not something I feel strongly about. Regardless of what is done there, I think we're all in agreement that the current behavior where it takes the Fcc from the replied-to message is wrong, right? I can't possibly imagine that was desired behavior (it's actually hard with nmh to send a message with a Fcc: header). --Ken _______________________________________________ Nmh-workers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
