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.
