On Tue, Nov 05, 2013 at 06:30:19AM -0600, Felipe Contreras wrote: > On Tue, Nov 5, 2013 at 5:43 AM, Oswald Buddenhagen <[email protected]> wrote: > >> A simpler and saner approach to deal with the problem is to simply > >> throw a warning: "There are still %i unsynchronized messages but we > >> reached the maximum limit". > >> > > that doesn't help with selectively picking the unread mails. > > Sure it does. The user can increase the limit to get those, if that's > what he wants. Or use a more appropriate option (AlwaysFetch: Recent). > If that matters for him. > it's not sane to require a user to fetch his entire archive to read a few omitted messages. ;)
> > well, mbsync assumes that subsequent fetches get higher and higher uids. > > incrementally extending the lower bound poses an interesting challenge. > > But that's true for both MaxMessages and MaxAge, no? > correct. > > so what are your priorities, given the effort (and consequently timing) > > estimates? > > - AlwaysFetch (easy) > > This is by far the most important I think. As it has been said before > lots of people _need_ MaxMessages for mbsync to be useful, and if they > have lots of unread messages they also need this option or MaxMessages > is not that useful. > this is now done in the maxmessages branch. the option is called ExpireUnread yes/no - i found that a) completely dumping the notion of "recent" makes sense and therefore a tri-state variable makes no sense and b) "fetch" is inaccurate, because it behaves symmetrically (omit fetch vs. prune existing). ------------------------------------------------------------------------------ November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk _______________________________________________ isync-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/isync-devel
