>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
