<<< Date Index >>>     <<< Thread Index >>>

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.