[2017-07-09 15:43 +0200] Philipp Takacs <phil...@bureaucracy.de>
> [2017-07-08 15:15] markus schnalke <mei...@marmaro.de>
> > Currently, however, I rather see the situation this way: Pick(1)
> > sets sequences, just like mark(1) but by conditions. Listing the
> > results (`pick -list') and showing them (scan/pick merge) are
> > structurally rather special tasks, which we provide for
> > convenience.
> > 
> > Well, maybe we should first get the relations between mark(1),
> > pick(1), and scan(1) clear. As I think about then, I realize
> > that don't have them as clear as I thought I would.
> 
> I see the situation a bit diffrent: Pick is like find, to search
> messages. The merge of scan/pick is adding a ``-form'' switch to
> pick and realising scan is now obsulet. I wouldn't have sugested
> the ``-form'' swtich for pick, if there wasn't the benifit of
> removing the hole scan tool.
> 
> The situation with pick and mark is a bit diffrent. Mark is the
> main tool to handle sequences and pick has one of its feature
> implemented. I don't see a clean way to merge these two tools.

Outsider's 2c:

Granted i don't use sequences beyond 'u', my mental picture is about
the same - pick(1) is for selecting messages, mark(1) - for working
sequences. The -seq option with pick(1) came off as a shortcut for
doing `mark $(pick ...) -seq ...`.

Reply via email to