Hi Ralph
[2022-04-01 13:41] Ralph Corderoy <ralph@inputplus.co.uk>
Ralph wrote:
Ok I see this more the other way around, pick shoundn't write
sequences, there is mark(1) for this.
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.
The thing is some decades ago is some decades ago ;-)
So is this limitation still relevant? And are there other solutions
like let mark read from stdin or use xargs?
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.
If this would be added to pick, then scan would be obsolet.
If all commands grew message-set expressions, like pick's, then pick
would be obsolete. ;-) mark(1) would do when the sequence only
needs modifying without display.
Yes, but would it be reasable to add message-set expressions to all
tools? As you pointed out they where removed some time ago.
No, they weren't. I didn't point that out. They have only ever been
arguments to pick.
Yes sorry I mixed this up a bit. I still don't think is reasonable to add
message-set to all tools.
With leads to the question: Why does pick only print out message
numbers and not a mh-format(5). The obvious awnser is: Because there
is scan for this. But you could also ask: Is scan (as an extra tool)
required at all? A -form switch on pick would do the same with the
same interface.
You're missing the essence of what each command is intended to do.
What is the one thing which currently make pick distinct from all the
other nmh commands? It is the ‘matcher’ arguments like ‘-subject’.
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.
- scan's single purpose is a one-line summary of a message, perhaps just
the message number.
- show's single purpose is to display a message over multiple lines.
- mark's single purpose is to manipulate sequences with set-like
operations.
I should break down what I want to do so I can cover the operations with
nmh's commands and then they compose.
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. Yes, with my
suggestion there would be no tool to display a one-line summary.
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.
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.
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. This may was
different at the time of implementing pick, but I look at it from a
today's perspective.
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.
Philipp