nmh-workers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: merge pick and scan


From: Philipp Takacs
Subject: Re: merge pick and scan
Date: Tue, 29 Mar 2022 18:49:22 +0200

[2022-03-29 05:05] David Levine <levinedl@acm.org>
> > 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]