I can understand that a changed behavior is a problem. But in this case
I would argue there is no other way. Every patch witch tries to fix this
will change the existing behavior, because the existing behavior is the
problem.
Right, I get that. But as Paul Fox points out, plenty of people have
come up with workarounds for this behavior and I'm reluctant to break
that. The eternal problem, sigh.
So I would prefer no option. But if you want one, I can add an option.
I would prefer the new behavior be the default. Also I would prefer a
build time option over a runtime option. I'm bad at naming, has someone
an idea for the name of such an option.
Oof, well, if we've learned ONE thing after all of these years, it's
that build time options are terrible, TERRIBLE ideas. The big reason
is that most users use a nmh install from a distribution, so whatever
configuration they end up is based on the person who created the
distribution build. I think build time options are fine for things
that require external libraries (e.g., TLS or Cyrus-SASL support)
but to change user behavior I think this is definitely sub-optimal.
So in general, I think the options are:
1) Make the new behavior the default, and require that anyone who wants
the old behavior add a switch (that will will allow existing setups
to work but it will require that people who have those setups to
change something)
2) Make new behavior optional with a switch
3) Make new behavior the default but try to auto-detect if a user has
a customized reply configuration.
I understand where you're coming from in that the current behavior is a bug
and the default should just work; I agree! So to me that completely
eliminates #2 as an option. Is #3 feasable? Not sure; I'll have to think
about it.
Also, just thinking out loud; should the default maybe be
"mhshow | sed -e 's/^/>/'"?
--Ken