Re: merge pick and scan

[Philipp Takacs]

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