Hi David [2022-03-30 08:39] Ralph Corderoy <ra...@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