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
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers