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 -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.
- 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.
Now, that can be a cumbersome user interface, but ~/bin exists. And
enhancements can be made if they're orthogonal, e.g. they don't add
exceptions.
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. 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.
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.
--
Cheers, Ralph.