Hi Philipp,
> Ralph wrote:
> > > 1. selected messages from a folder 2. unselect messages with don't
> > > match the given pattern 3. Print out all selected messages
> >
> > I don't think pick(1) does item 2, unless you mean by virtual
> > [virtue] of item 1 leaving some messages out.
>
> Yes I mean this more virtual, the implementation details are not realy
> importend for my point.
>
> > And I think it shouldn't do item 3. When sequences were added to MH
> > and pick altered to define them, scan(1) could have been used to get
> > the message numbers, similarly to how you suggested earlier.
>
> 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.
It would have been annoying for a search with pick which produced many
messages to be awkward to store in a sequence by requiring multiple runs
of mark, building up the sequence piecemeal. Or for
refile `pick ...` +foo
to not be run by the shell because too many messages were matched. Thus
sequences were created to store pick's results and all commands which
accepted message numbers altered to also accept sequence names.
One could argue, not that I am, that pick should have always listed the
message numbers and sequences need not exist, but limits of the day
prevented that.
> I don't know whitch suggestion you mean. I guess you mean something
> to get the message numbers of a sequence.
Yes.
> To get these you can currently choose between "pick seq",
Only with ‘-list’ which you may have as a default in your ~/.mh_profile.
> "scan -format '%(msg)' seq"
That's the one I was thinking of.
> and "mark -list -sequence seq". The last one prints the contet of
> .mh_sequences and is special for sequence management.
mark's output isn't suitable as a list of message numbers to pass to
other commands, even with ‘-norange’.
> But the scan and pick version do more or less the same.
Yes.
> > > Scan:
> > >
> > > 1. select messages from a folder
> > > 2. Print out all selected messages
> > >
> > > The function of the two tools looks overlapping.
> >
> > Agreed, but compounding the wrongs doesn't make a right. :-)
>
> Are they realy that wrong or is this a question of the perspective?
Oh, this is subjective to an extent.
> From my point of view pick does message selection and printing. The
> sequence handling is kind of an odd feature.
>
> If I understand you correct you see pick more as a tool to add
> messages to a sequence and the -list switch is kind of odd.
Yes, pick was created to search for messages to store in a sequence, and
sequences created at the same time. pick's ‘-list’ duplicates scan(1)'s
functionality. pick taking message numbers and no ‘matcher’ arguments
duplicates mark's functionality.
> So in both views pick can do something which don't realy match. Also
> there are other tools (scan and mark) with can do parts of the
> functions better. So it's reasonable to ask what is the purpose of
> pick. My suggestion would clarify the purpose.
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.
> > > 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.
> This would also require all tools to read and parse the messages.
> Currently not all tools (i.e. rmm) need to do this.
If ‘-subject foo’ were used when calling rmm then yes, it would need to
read messages, but ‘rmm 42 314’ wouldn't bother to read 42 or 314. The
processing of the ‘matcher’ arguments, like ‘-subject’, would be done by
library code called by all the commands which accepted them. Just as
common code now allows a sequence name to be used in place of message
numbers.
> But looking at pick: pick already reads and (somehow) parses the
> messages. A -form/-format switch would only add a way to print this
> information.
It would compound the errors already made to pick.
pick -seq foo 42 314 # Should be mark(1).
pick -seq foo -list -subject foo # Should use scan(1) afterwards.
> 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
