Oswald Buddenhagen wrote: > 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've tried this and it indeed works, however, I don't find the name intuitive. First of all it's not easy to see that MaxMessages and ExpireUnread are related. Maybe if the option was MaxMessageToNotExpire, but that is not inutitive at all. Moreover you start from the assumption that people would automatically assume unread messages are not included in this limit, and I think it would be the opposite for most people. I think LimitExcemptUnread is much clearer because a) it explains what the option affects; limits (which could be MaxAge, MaxMessages, etc.), b) the word except makes it clear that the limit rule doesn't apply to this kind of messages. > - i found that a) completely dumping the notion of "recent" makes sense and > therefore a tri-state variable makes no sense Seems sensible to me. > and b) "fetch" is inaccurate, because it behaves > symmetrically (omit fetch vs. prune existing). Indeed. -- Felipe Contreras ------------------------------------------------------------------------------ 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
