Re: merge pick and scan

[Ralph Corderoy]

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.