Re: [Nmh-workers] Quiting mhshow(1) Early Doesn't Set CurrentMessage.

[David Levine]

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