Re: merge pick and scan

[Ralph Corderoy]

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.