Peter Maydell writes:
Is there any reason why it shouldn't allow any random
whitespace between
message numbers?
Room for future expansion? Folders with spaces in names?
I'm just used to thinking of newline-delimited rows, I guess.
I'm slightly against allowing spaces, but only slightly. I guess
if I implement folder changing later, we could say not to put
message numbers after folders; anything between + and newline is
the folder name.
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'.
Oops, of course I meant 'scan 4 3'. Obviously 'scan 3 4'
couldn't possibly print the messages in any order but 3, 4 :).
Just for consistency (and because you'd probably want to
implement it
by having common code for doing this).
I'll take a whack at it, as long as it doesn't mean refactoring
too much old, painful code.
less at least seems happy with
stdin being /dev/null, as does my editor, so I think that
argument is
a red herring.
Huh, OK. Bad assumption on my part.
Sounds good. (I couldn't remember whether nmh wrote sequences
in sorted order.)
Near as I can tell, it never deals with message numbers in
anything but sorted order, by the very nature of the structure it
uses for them.
line not being sorted either). [I appreciate that doing things
this
way would be a fairly big change, though.]
We'll see. I'll start with show; do you have any other commands
in mind? I'm just not feeling foo | refile; I don't see any way
it's better than refile `foo`, unlike scan and show, where you
want to see immediate output.
Thanks.