Re: [Nmh-workers] [PATCH] scan message numbers from stdin

[Peter Maydell]

Eric Gillespie wrote:
>So, you want
>
>  printf '%s\n' 1 2 3 4 5 | scan -

Is there any reason why it shouldn't allow any random whitespace between
message numbers?

>Peter Maydell writes:
>> I think that it would be nice if 'scan 4 1 2' actually output the messages
>> in the order stated on the command line. I also think that it would be
>
>I, too, would rather 'scan 3 4' print the lines in that order
>(first 3, then 4). 

That it already does. The question is what it does (or should do) if you
say 'scan 4 3'.

> In any case, having scan - sort the messages
>entirely defeats its purpose (scan as you go).

I agree.

>> better if all programs accepting multiple messages allowed you to specify
>> '-' to read from standard input -- why should 'scan' in particular be
>> special?
>
>I suppose it shouldn't.  Which other commands should take the -?
>Not show or repl; editors and pagers are likely not going to
>appreciate standard input being connected to an empty pipe.
>refile I suppose.  Hmm, 'foo | pick - | scan -' :)?  Sure, why
>not?  Anything else?

I think the two possible right answers here are:
 * any program which accepts multiple message numbers
 * any program which accepts at least one message number

Just for consistency (and because you'd probably want to implement it
by having common code for doing this). less at least seems happy with
stdin being /dev/null, as does my editor, so I think that argument is
a red herring. (And 'echo 1 2 3 4 | show -' is one of the things I thought
it would be nice to have working.)

>> (Extra bonus UI question: if we make scan process messages in the order
>> stated rather than always sorted order, what should 'scan sequencename'
>> do if the sequence as defined in the .mh_sequences file isn't in order?)
>
>I say it should scan messages in the order it finds them in
>.mh_sequences, and mh itself should continue to write messages
>into that file sorted.  If any sequence is listed with messages
>in some non-sorted order, the user must have put them that way
>for a reason.

Sounds good. (I couldn't remember whether nmh wrote sequences
in sorted order.)

>> So I guess I like the idea but not the implementation.
>
>Hmm, you didn't say a word above about the implementation.
>You voted (unless I misread you) for scan not sorting the
>messages, so I guess that's not what you're against (and even if
>you were, that's a design choice, not implementation).  Can you
>lay out your objections, so that I may address them in my patch,
>or realize that the change is not going in?

I meant that I'm happy with the idea of scan taking message numbers
on standard input, but that I don't like the implementation you've
done (with scan as a special case), and would prefer a more general
approach (as outlined above, and with message numbers on the command
line not being sorted either). [I appreciate that doing things this
way would be a fairly big change, though.]

-- PMM