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.
