Re: [Nmh-workers] I did something wrong with replcomps

[Ken Hornstein]

>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