>OK, took a look. The thread doesn't clearly indicate to me that things were >going to be broken as opposed to the addition of a new feature. Remember me? >I'm the don't-break-stuff guy.
I went back and looked; I included a bulleted list of changes. I thought that was pretty obvious, especially when I said (exact quote): - By default only display text, inline content (basically, default to -type text). I feel at times we have two conflicting impulses in nmh: 1) Don't break user behavior 2) Improve nmh, especially when it comes to MIME handling. So these things are sometimes in conflict. I think the vast majority of people would agree that the default mhshow behavior is awful. Sure, it might have been reasonable when MIME messages were rare, but now they're the standard. The old behavior simply did not make sense; it had to be changed. So we're starting from different initial conditions: you're saying, "Hey, you made a default behavior change: that breaks stuff for existing users!". My initial condition is: "This thing is broken by default, it has to change to become less broken". And I feel it's worth pointing out that we were just talking about changing the default behavior; you could still get the old behavior back (minus support for stuff that we completely dropped). The people who objected at the time this change was proposed were all people who had developed what might politely be called workarounds to mhshow's broken behavior. I can understand someone who developed a script 15 years ago to deal with mhshow's brokenness being grumpy that they had to change something, but I can't really accept it as an argument that the default behavior was reasonable. So I would make the case that we needed to change the defaults and that people who wanted the old behavior could get it back by adding a few new switches to their mh_profile. I don't set out to screw anyone over, but I can't really see how it's unavoidable unless we want to have nmh have completely horrible default behavior from now until the end of time. Now if you want to make the case that mhshow's previous behavior was fine, well, let's hear that argument. I can't promise I'll undo the change, but I'm willing to listen to your perspective. >I think that this is pretty broken from a user perspective. Not the >current change, but having both show and mhshow. I would just use >mhshow for everything except that it doesn't do next and prev. And >I can't use show for everything because it doesn't understand -part. >Well, it sort of since "show -part 1" makes message number 1 the >current message but that's not the result that I expected either. And >"show -part 2" gives and error message and sets cur to 2. Seems like a >bug. Well, it's important to see how we got here. mhshow is part of the split off of the old mhn command, which handled MIME display and composition. That was where mhbuild and mhstore came from. No one would agree that this situation is ideal. show was modified so it would pass along unknown arguments to mhl and/or mhshow, and by default if it detects if the message is MIME it will invoke mhshow. So "next" and "prev" work in the normal case, because they're really invoking show, which will end up calling mhshow. I think this is a huge improvement over the old mhn command. The issue here is the -part switch is passed down to mhshow, but show doesn't know that -part takes an argument, so it interprets the part number as a message argument. That's a bug, definitely. But I think pretty much everyone agrees with you that mhshow is a bug and should go away; it's functionality should be subsumed by show. That's one of my long-term goals to go along with more complete MIME integration; more on that in a later email. --Ken _______________________________________________ Nmh-workers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
