On Tue, Jul 12, 2005 at 10:38:44AM -0700, Brendan Cully wrote:
> On Tuesday, 12 July 2005 at 15:00, Vladimír Marek wrote:
> > Hello,
> >
> > > On Mon, Jul 11, 2005 at 04:26:59PM -0400 I heard the voice of
> > > John J. Foster, and lo! it spake thus:
> > > >
> > > > Yes, they are new mail, complete with an N flag. However, they are
> > > > not reflected in the mailboxes screen. Enter any folder with new
> > > > mail, and immediately leave that folder. The mailboxes screen does
> > > > not show that folder as having new mail.
> > >
> > > Well, it does, for me. But I'm using maildir, so I'd expect that. I
> > > can't think of how you'd handle it in mbox without having to parse the
> > > whole thing, though. Icky.
> >
> > sorry for joining here so late. Maybe a bit OT in this thread, but it's
> > behaving differently even on IMAP folders. Back to the topic. I wrote a
> > patch for this and submitted here according to all rules. No response.
> > I wouldn't mind if someone told me that
> > * this patch is bad ( which probably is, since it's my first adventure
> > with mutt sources )
> > * it's feature creeping ( I doubt that, since for me it's doing IMAP
> > in mutt quite unusable )
> > * it's not usefull to many people ( I doubt that, since I actually met
> > someone on #mutt asking for this, and I was like five times on #mutt
> > in my whole life )
>
> Sorry about that. Here's my opinion:
> - I like not being prompted to go back to a mailbox that I've just
> left, so I haven't felt any pressing need to work on new mail
> handling.
Do you answer all your mail right away, or how do you solve when there's
more mails which require your attention ?
> - your patch is fine, but I didn't want to include it for two
> reasons. 1: yet another tiny config variable, which should probably be
100% agree, but I don't see beter solution, at least solution which I'm
able to implement
> generalized across maiilbox formats, and 2: mutt's IMAP mail
> detection is wrong anyway. The recent flag is basically broken by
> design (especially if you have multiple clients connected at the
> same time), and should be replaced by a UIDVALIDITY check. This
> means squirreling a little more data away in the buffy list, which
> in turn makes me think that general mailbox info should be cached
> somewhere (to record things like number of messages, number of
> flagged, number of new, number of unread etc), which leads to bigger
> architectural changes than I've had time to consider. The IMAP code
> is crusty enough that this happens to me all the time - little
> features get put off for until after the bigger rewrite that never
> happens. I'm not proud of that. Anyway, if mail handling is fixed,
> your patch probably won't work the same way and becomes a backward
> compatibility problem.
I don't insist on my patch, I would be glad for any solution :)
> - also, as one of us has been keen to point out, mutt's new mail
> handling in general needs some TLC that may invalidate a number of
> proposed workarounds.
If we are able to admit that there's problem, we're halfway done :)
Since this problem touches me personally I am willing to help.
--
Vladimir
Attachment:
pgpt861hlQ7J2.pgp
Description: PGP signature