Re: merge pick and scan
[2022-04-21 14:49] Eric Gillespie > And it gets even worse: first you have to wait for pick to slowly > search ALL THE FILES (within limiting message range you may have > given it if you have any idea and often I did not), and then you > wait for scan to slowly readdir everything, and THEN you finally > get your results. What I really want (and I doubt I'm alone) is > scan lines as soon as a message is a HIT, so I can interrupt when > the message I'm looking for comes across, without waiting for any > further work. It's even worse, because pick don't read a message once, it reads the message for eatch action. There is a optimization to not perform eatch action on the message, but this depends on the given actions and the messages. So for example have the following command: > pick -from bla -and -subject blub All mails from bla will read twice. So if you know you have only a few messages with the subject blub and many messages from bla, switching the actions will increase the performance of pick. To avoid this pick could read the message per field[0] and check for a match. Yes the actions do early return, but this also depend on the messages and the libc/fs could do some read optimication. But in general pick does many IO-operations which aren't necesary. In general there could be a pattern to read a mail/header before processing and store the required fields. All the follow up processing could be done without IO operation. > On a modern filesystem on SSD in 2022 maybe nobody cares anymore. > But over NFS in 2010, this mattered a lot. I think this still matters, not in the way that we must optimice every operation, but nmh sould avoid wasting time. Philipp [0] I only think of header search, because body search don't work good on most mails I get (MIME).
Re: merge pick and scan
Eric Gillespie wrote: > I guess no one has network-mounted home directories anymore. I don't. Well, I do. I wish I had home directories over disconnected AFS, but that never happened for me. ... > I definitely plan to resurrect that patch soon because... Guess another > case where having scan repeat pick's expensive work comes into play. > Yep, it's over there on that imap-prototype branch. I was just thinking about that. signature.asc Description: PGP signature
Re: merge pick and scan
> On Apr 21, 2022, at 7:12 PM, Ken Hornstein wrote:
>
>>> You see, nmh's dirty secret (ok ok, one of many!) is that the
>>> first thing every command does is read the entire directory.
>>> Yep, the whole thing.
>>
>> If you use any syscall tracer, you will see that this is not what
>> happens. scan & pick will do a directory read only if no messages
>> are specified because the default is all. Otherwise they only touch
>> specified messages.
>
> You are incorrect.
>
> % strace scan 5705
> [...]
> chdir("/users/kenh/Mail/inbox") = 0
> openat(AT_FDCWD, "/users/kenh/Mail/inbox", O_RDONLY|O_NONBLOCK|O_CLOEXEC
> |O_DIRECTORY) = 3
> access("/users/kenh/Mail/inbox", W_OK) = 0
> getdents(3, /* 1365 entries */, 32768) = 32768
> getdents(3, /* 1365 entries */, 32768) = 32760
> getdents(3, /* 829 entries */, 32768) = 19912
> getdents(3, /* 0 entries */, 32768) = 0
> close(3)= 0
> [...]
I just did "kdump|egrep -i 'nami|open|read'" -- I was forgetting
things have changed in Unix and we no longer read(2) a directory!
Thanks!
> Anything that needs a "struct msgs" for a folder has to call
> folder_read() (which is almost all nmh programs) and folder_read()
> calls readdir() on the whole folder.
pick seems to even read the whole dir twice!
Modern unixes cache dir entries so the cost can't be too bad
(no idea about NFS as I try to avoid it).
>
> (I've got more to say about the original proposal, but ... tomorrow).
>
> --Ken
Re: merge pick and scan
>> You see, nmh's dirty secret (ok ok, one of many!) is that the
>> first thing every command does is read the entire directory.
>> Yep, the whole thing.
>
>If you use any syscall tracer, you will see that this is not what
>happens. scan & pick will do a directory read only if no messages
>are specified because the default is all. Otherwise they only touch
>specified messages.
You are incorrect.
% strace scan 5705
[...]
chdir("/users/kenh/Mail/inbox") = 0
openat(AT_FDCWD, "/users/kenh/Mail/inbox", O_RDONLY|O_NONBLOCK|O_CLOEXEC
|O_DIRECTORY) = 3
access("/users/kenh/Mail/inbox", W_OK) = 0
getdents(3, /* 1365 entries */, 32768) = 32768
getdents(3, /* 1365 entries */, 32768) = 32760
getdents(3, /* 829 entries */, 32768) = 19912
getdents(3, /* 0 entries */, 32768) = 0
close(3)= 0
[...]
Anything that needs a "struct msgs" for a folder has to call
folder_read() (which is almost all nmh programs) and folder_read()
calls readdir() on the whole folder.
(I've got more to say about the original proposal, but ... tomorrow).
--Ken
Re: merge pick and scan
On Apr 21, 2022, at 1:21 PM, Eric Gillespie wrote: > > You see, nmh's dirty secret (ok ok, one of many!) is that the > first thing every command does is read the entire directory. > Yep, the whole thing. If you use any syscall tracer, you will see that this is not what happens. scan & pick will do a directory read only if no messages are specified because the default is all. Otherwise they only touch specified messages.
Re: merge pick and scan
I thought I would sit back and wait to see where this went. I was surprised and disappointed no one brought up the huge performance cost of the current implementation. I guess no one has network-mounted home directories anymore. I don't. But for many years that was where my mail lived. And lots of it! If you review my messages to this list over the years, you'll notice a recurring pattern about optimizing away those slow directory reads. You see, nmh's dirty secret (ok ok, one of many!) is that the first thing every command does is read the entire directory. Yep, the whole thing. So, the `new` commands that I added carefully avoided the readdir. But combining scan and pick on NFS is even worse than that though, as both have to open message files too! And it gets even worse: first you have to wait for pick to slowly search ALL THE FILES (within limiting message range you may have given it if you have any idea and often I did not), and then you wait for scan to slowly readdir everything, and THEN you finally get your results. What I really want (and I doubt I'm alone) is scan lines as soon as a message is a HIT, so I can interrupt when the message I'm looking for comes across, without waiting for any further work. I offered a patch at some point to have scan read message numbers through standard input so you could `pick ... | scan -` so you could skip the second readdir AND get early interrupt. I'm not sure what happened to that one, but I'm not disappointed it didn't make it in. It's really only a half measure. On a modern filesystem on SSD in 2022 maybe nobody cares anymore. But over NFS in 2010, this mattered a lot. I don't see how we can argue that "the UNIX philosophy" means every command has to repeat the same expensive work and also they're not allowed to share code. Well they already share plenty of code... just not that code! :) I think the philosophy case falls down in other ways as well. pick does three things: 1. resolve user query to message numbers 2. by default, print the message numbers without formatting 3. optionally, store in sequence scan already implements a subset of #1 (as do all commands accepting message specifications). #2 is pick duplicating scan's job (scan -format '%(msg)'). #3 is pick duplicating mark's job. I think I still have an old patch lying around somewhere that teaches pick to scan when `-scan` option is given. I definitely plan to resurrect that patch soon because... Guess another case where having scan repeat pick's expensive work comes into play. Yep, it's over there on that imap-prototype branch. I'll be sure to bring numbers into that discussion when the time comes :) Thanks!
Re: merge pick and scan
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.
Re: merge pick and scan
Hi Ralph [2022-04-01 13:41] Ralph Corderoy > > Ralph wrote: > > 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. The thing is some decades ago is some decades ago ;-) So is this limitation still relevant? And are there other solutions like let mark read from stdin or use xargs? > > 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. > > > > 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. Yes sorry I mixed this up a bit. I still don't think is reasonable to add message-set to all tools. > > 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. The point where we disagree is what should pick do with the matched emails. > - 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. > > 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. Yes, with my suggestion there would be no tool to display a one-line summary. 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. > 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. > 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. This may was different at the time of implementing pick, but I look at it from a today's perspective. > 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. Philipp
Re: merge pick and scan
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
Re: merge pick and scan
Hi David [2022-03-30 08:39] Ralph Corderoy > > 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
Re: merge pick and scan
Hi Conrad, > but here's a case that is currently unambiguous (because MH commands > have side effects) that might cause complications for general switch > parsing: > > refile +foo `pick ... +bar` I agree. The search folder would have to be set first as refile's folder would always be the destination to remain backwards compatible. folder +bar refile +foo -from foo > Indeed, why wouldn't we then want to say > > refile -from john +* +foo At some point, the syntax can't handle what ever's required and multiple commands would be necessary. But given ( and ) should be synonyms for -lbrace and -rbrace anyway, borrowing from find(1), perhaps refile +foo \( -from john ++\* \) # Like bash's globstar. But I have been thinking about sequences which span folders. Is a sequence really just an optimisation of a folder containing linked messages? Except that an empty sequence is, wronly IMO, not supported. This opens the path to all messages in a single store with folders/sequences being ‘views’ onto those messages. Then do folders move to an implementation more like sequences? With a ‘synchronise export’ operation to bring a directory tree up to date with a sequence/folder. -- Cheers, Ralph.
Re: merge pick and scan
[2022-03-30 10:41] Conrad Hughes > I'm somewhat neutral on this — can see the convenience etc. — but here's > a case that is currently unambiguous (because MH commands have side > effects) that might cause complications for general switch parsing: > > refile +foo `pick ... +bar` > > .. if pick's args were merged into refile's, then order of arguments > becomes even more significant: I belive I there is a big missunderstanding. I don't want to add pick's args to scan (or an other tool). I want to add scan's -form/-format to pick. So no other tool should be affected. I don't think it's reasonable to add the pick args to another tool. As David already pointed out this was seen as `inverted logic' and therefor removed. I don't want to bring it back. Philipp
Re: merge pick and scan
I'm somewhat neutral on this — can see the convenience etc. — but here's a case that is currently unambiguous (because MH commands have side effects) that might cause complications for general switch parsing: refile +foo `pick ... +bar` .. if pick's args were merged into refile's, then order of arguments becomes even more significant: refile ... +bar +foo or refile +foo ... +bar ? I mean, if we were to treat refile like mv, then arguably you should be able to do something like refile ... +baz ... +bar +foo .. but I think it becomes obvious that a potentially major general overhaul would be required to make sense of things. Indeed, why wouldn't we then want to say refile -from john +* +foo etc. Can of worms. Justified? If you've got the time, maybe. Conrad
Re: merge pick and scan
Hi again Philipp, > 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. 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. > 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. :-) > 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. Now, you could ask how can I support the Unix Philosophy of ‘do one thing well’ and that pick should not have -list but that all commands should grow ‘-from foo’? Well, it's the demarcation of that one thing. ‘grep -l’ was good enough before pick came along and when better functionality was needed it was presumably easiest to concentrate the new experimental syntax in a new command rather than come up with a syntax which didn't conflict with all the different commands existing arguments. With hindsight, and decades of improvement in computing power, I think a general syntax for describing sets of messages, including the empty set, available to all nmh commands which manipulate messages would be more orthogonal. Mercurial's ‘revset’ notation is an example of the kind of thing, e.g. to remove all messages from foo and any replies to them and replies to replies ad infinitum by making use of the threading fields: rmm 'descend(from:foo)' > > 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. -- Cheers, Ralph.
Re: merge pick and scan
Hi Philipp, > To scan selected messages currently a combination of scan and pick is > used. It would be nice to be able to write something like: > > scan -from bob > > In order to do this we could add the -form/-format switches to pick > and make scan a link to pick. To avoid most breakage pick would use > "%(msg)" format by default and scan.default if called as scan. This > way only some scan aliases would break (if -form/-format is not > explicitly set for them). All other usages would still work. Did you know pick(1) says HISTORY In previous versions of MH, the pick command would show, scan, or refile the selected messages. This was rather “inverted logic” from the Unix point of view, so pick was changed to define sequences and output those sequences. Hence, pick can be used to generate the arguments for all other MH commands, instead of giving pick endless switches for invoking those commands itself. I'm generally not in favour because it seems to be combining two specific things rather than thinking more orthoganally. For example, I'd quite like to do refile +archive -from foo -and -subject bar forw -mime -date '01 Apr' IOW, make pick's expressions first-class citizens of all nmh command parsing. Except I think the syntax is wordy and something like refile +archive from:foo subject:bar would be better, including the implicit logical conjunction. -- Cheers, Ralph.
Re: merge pick and scan
[2022-03-29 05:05] David Levine > > In order to do this we could add the -form/-format switches to pick and > > make scan a link to pick. To avoid most breakage pick would use "%(msg)" > > format by default and scan.default if called as scan. This way only some > > scan aliases would break (if -form/-format is not explicitly set for them). > > 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 Scan: 1. select messages from a folder 2. Print out all selected messages The function of the two tools looks overlapping. There are two diffrence: First the secound step of the message selection on pick is not there in scan. Secound the print out of pick only prints a hardcoded format. So my suggestion is basicly to extend the print function of pick to allow printing in a user defined format. The data for the print format is already read by pick[0]. If this would be added to pick, then scan would be obsolet. > 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. Also I don't sugguest to completle redesigne the interface from scratch and the breakage would not affect many cases. The most affected case would probably be something like ``scanf: first'' and it can be fixed by adding ``-form scan.default'' to the config. Philipp [0] I have some other improvements in mind which would allow to better handle the mail header and avoid double parsing.
Re: merge pick and scan
david wrote: > Philipp wrote: > > > In order to do this we could add the -form/-format switches to pick and > > make scan a link to pick. To avoid most breakage pick would use "%(msg)" > > format by default and scan.default if called as scan. This way only some > > scan aliases would break (if -form/-format is not explicitly set for them). > > There needs to be really good justification for intentional breakage. > I don't think that departure from the Unix philosophy can be > considered good for nmh. Agreed. Can't the scan/pick combo be readily done with a shell function? paul =-- paul fox, p...@foxharp.boston.ma.us (arlington, ma)
Re: merge pick and scan
Philipp wrote: > In order to do this we could add the -form/-format switches to pick and > make scan a link to pick. To avoid most breakage pick would use "%(msg)" > format by default and scan.default if called as scan. This way only some > scan aliases would break (if -form/-format is not explicitly set for them). There needs to be really good justification for intentional breakage. I don't think that departure from the Unix philosophy can be considered good for nmh. David
merge pick and scan
Hi To scan selected messages currently a combination of scan and pick is used. It would be nice to be able to write something like: > scan -from bob In order to do this we could add the -form/-format switches to pick and make scan a link to pick. To avoid most breakage pick would use "%(msg)" format by default and scan.default if called as scan. This way only some scan aliases would break (if -form/-format is not explicitly set for them). All other usages would still work. It would still be possible to call: > scan `pick -from bob` I have implemented this for mmh and could port it to nmh. What do you think of the idea? Philipp
