Re: mutt development status
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.
- 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
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.
- 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.