Ralph wrote:
Hi David,
show(1) doesn't quite do the right thing either. Quitting before the
last message of many has a different but equally disturbing effect:
the current message is set to the last selected message, even though
it was never shown.
I'd forgotten that, but have been bitten.
Does anyone disagree that we want this behavior instead, from the
show(1) man page, for both mhshow and show?
The last message shown will become the current message.
No, I think show's current behaviour is correct. Besides, if it's just
printing them end-to-end on stdout then it can't know how far through
that stream my eyeballs have got in less(1) what with pipe buffering.
If I do `show 42-314' then it's nice, even if I bail, to know `show
next:271' repeatedly does another chunk that doesn't overlap.
OK, that makes sense.
I'll update the show(1) man page to say "selected" instead
of "shown". Then it will be consistent with the
implementation and the other man pages.
And just to note that the other commands that set the current message
and can take multiple messages behave differently. Some set the first
message of many to the current message, while others set the last. I
don't think that we want to change them at this point
Agreed, but the inconsistency smells? Anyone have a reason why show's
behaviour can't be the desired target long-term?
Just anno, forw, and mhshow, I think, would have to change
to be consistent with the others.
David
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers