Hoi.
[2017-07-08 14:51] Philipp Takacs <phil...@bureaucracy.de>
> [2017-07-07 11:58] markus schnalke <mei...@marmaro.de>
> > [2017-07-07 11:32] Vasily Kolobkov <polezaivs...@openmailbox.org>
> > > [2017-07-07 10:30 +0200] Philipp Takacs <phil...@bureaucracy.de>
> > > > While doing this we could also remove the -[no]list, -sequence
> > > > and the -[no]zero switches.
> > >
> > > You mean dropping writing to sequences aspect altogether? I haven't
> > > ever used this function once. If others find it of no use as well,
> > > i'm all for slaying some code :)
> >
> > I do use -seq always! I think we can remove -list when we the
> > pick/scan merge is done, but -seq and -zero have to stay.
>
> I think this three switches work only together. I'll explain this
> later.
>
> > Mark(1)
> > and pick(1) are the two tools that provide marking sequences,
>
> This is why I want to remove the -seq switch from pick, I don't
> think we need two tools for the same task.
I generally agree. But I don't see how mark(1) could cover the
pick(1) task.
The scenario is such:
I want to handle all messages from bob as a group (show them,
refile them, remove them, etc.) Thus I use a sequence for them.
But as they are scattered over the whole folder I cannot simply
`mark l:20' but rather have to `pick -from bob'.
Now, how do I get them into the sequence if pick(1) doesn't do
it for me? (Keep in mind, I don't necessarily want to show them,
but rather refile them.)
If we can cover this scenario without pick(1) needing the -seq
switch, then we can consider dropping it.
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 would say remove all this sequence handling from pick, because we don't
> need two times the same code. I really don't see any benefits by having
> these switches.
Maybe we should collect some scenarios.
My one is:
pick -from bob -seq P +inbox
refile P +bob
Finally: It's good to discuss these points. They help us moving
forward and shaping mmh even better. So, keep going ...
meillo
