Hi Philipp,
Yes, if pick always listed by default then it could skip the writing
of sequences by passing them as arguments to mark. But bear in mind
the limit on the number of arguments to a process and their total
size in characters, especially some decades ago.
...
So is this limitation still relevant? And are there other solutions
like let mark read from stdin or use xargs?
The xargs(1) route is tedious and not what you'd do on the fly.
I suppose mark(1) reading from stdin would be an option.
I have a script which maintains several sequences as I interactively
move through emails and I suffer a noticeable delay on this old machine
due to calling mark(1) several times to update a different sequence each
time. Really, I'd like to run mark once giving it a list of what to do
per sequence for a number of sequences. Then it can just read and write
the sequences file once, speeding things up. The standard input route
wouldn't work for that if it were just a simple list of message numbers.
To get these you can currently choose between "pick seq",
Only with ‘-list’ which you may have as a default in your
~/.mh_profile.
Just a litle nitpick: "-list" is the default if no sequence is given.
Ah, then it's me that has a default: a -sequence for pick in my profile!
With the Unix ‘do one thing well’ outlook,
- pick's single purpose is to search emails with its ‘matcher’
operators.
The point where we disagree is what should pick do with the matched
emails.
Well, no...
- scan's single purpose is a one-line summary of a message, perhaps
just the message number.
You think pick should scan the matched emails, thereby merging two
one-things, pick and scan, into one. This is no longer ‘do one thing
well’. I agree that means we disagree what pick should do with matched
emails, but clouds the reason.
Moving the ‘matcher’ arguments from pick to all the other commands
would improve the UI and they'd be consistent in that ‘-subject’
could be given to all of them.
Then there would be no tool to match/search emails.
Correct. Just as no tool is needed to list a sequence's message
numbers, instead ‘show seqname’ works.
Yes, with my suggestion there would be no tool to display a one-line
summary.
Agreed. But I think that's a different operation to searching emails
and as long as searching is a distinct action, as opposed to all
commands accepting matcher arguments, then I think it should be a
distinct command.
Also as said earlier this would require all tools to be able read and
parse the mails. Yes this would be hidden in srb/, but still be there.
So all tools would match and do there purpose.
Yes, but it's no extra work. It's less because two commands and passing
data between them, either with pick's -list into argv[] or through
.mh_sequences, would not be needed.
Moving the ‘matcher’ arguments to just scan would be a wart. Yes, I
know you think of it as scan's one-line formatting moving to pick,
but it's the same thing looked at the wrong way around simply
because of how you see to implement it.
I see it this way, because of the way I use it. Most of the time I use
the matchers of pick, I search for the next mail to handle and
therefor use a combination of scan and pick. I don't use sequences
that much.
Ah, I pick and then move through a sequence. ‘n p’ shows me the next in
sequence p, pick's default for me, and ‘b p’ goes back. (Not ‘p’ for
prev(1)-ious because ‘p’ for me is pick(1). :-)
pick and scan overlap, but that's due to the error of adding -list
to pick and isn't a reason to merge the two.
I still see the error in pick in the -sequence switch.
Without sequences, all commands would need to accept message numbers on
stdin to work around argv[] limits which would hamper stdin's use for
other, more interesting, purposes.
Your suggestion is one interpretation and I don't think it's the
best one. Anointing your suggestion by making your change would
further muddle the two distinct operations of scan and pick.
I think here we are at a point we can agree to disagree.
Yes. :-)
--
Cheers, Ralph.