Hi David
[2022-03-30 08:39] Ralph Corderoy <ralph@inputplus.co.uk>
David wrote:
I don't think that departure from the Unix philosophy can be
considered good for nmh.
I don't quit understand this argument. From my perspective the current
interface don't match the Unix philosophy. To explain this lets look
what scan and pick do:
Pick:
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 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.
I don't know whitch suggestion you mean. I guess you mean something to
get the message numbers of a sequence. To get these you can currently
choose between "pick seq", "scan -format '%(msg)' seq" and
"mark -list -sequence seq". The last one prints the contet of .mh_sequences
and is special for sequence management. But the scan and pick version do
more or less the same. By implementing my sugguestion this would be also
the same code.
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?
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.
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.
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. This would
also require all tools to read and parse the messages. Currently not
all tools (i.e. rmm) need to do this.
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. 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. The implementation of this is not big and only affects
one tool. It don't change the general input interface, only the output
interface of pick.
There needs to be really good justification for intentional
breakage.
I hate this argument. Yes changing the user interface shouldn't be
done just because it feels good. But To improve the user interface it
must change sometimes.
But changing the user interface doesn't have to cause breakage.
Changing the user interface itself doesn't break only if you add a
new interface for an already existing feature. So in this case adding
-form/-format switches to pick without removing scan. This is possible,
but I don't see this as a good option.
Philipp