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

Re: For 1.5.9: attachment counting for index display



I haven't read the patch recently.

One question, though:  Would it imply that mutt would have to parse
every single message in a mail folder?  Or even every single new
message?

In that case, be prepared for it to increase mutt's memory
consumption significantly.  (I.e., in that case, I wouldn't like it
to be committed.)
-- 
Thomas Roessler · Personal soap box at <http://log.does-not-exist.org/>.






On 2005-09-12 19:29:48 -0700, Brendan Cully wrote:
> From: Brendan Cully <brendan@xxxxxxxxxx>
> To: mutt-dev@xxxxxxxx
> Date: Mon, 12 Sep 2005 19:29:48 -0700
> Subject: Re: For 1.5.9: attachment counting for index display
> Mail-Followup-To: mutt-dev@xxxxxxxx
> X-Spam-Level: 
> 
> On Monday, 12 September 2005 at 16:34, René Clerc wrote:
> > *bump*
> > 
> > Brendan, and / or Thomas,
> > 
> > Can you make a judgement about this patch?  I decided to bump this
> > thread because, as I've noted, nobody has responded to David's
> > message.  Furthermore, it's the only patch I use that has not been
> > applied to CVS..  
> > 
> > Most mailers have this functionality, e.g. through the display of a
> > paper clip or something like that.  I would *really* find this
> > useful.
> 
> I like the idea too. I just read the patch, and it seems sounds, but
> maybe somewhat overengineered? Does it really need attach-allow et al,
> or can we just have some "sensible defaults" eg ignore inline
> parts and pgp attachments. Actually the defaults in the patch look
> pretty reasonable, I'd be tempted to just hard-code them to save
> config bandwidth.
> 
> > Thinking about it some more:  would it make sense to alter this patch
> > somewhat, and to:
> > 
> > - not automatically parse the tree for Maildir and IMAP mailfolders,
> >   but display a "?" (or something like that, or nothing at all)
> >   instead?
> >   
> > - cache the attachment information for these types of folders?
> 
> I think it's probably worthwhile to either cache the number or simply
> not throw out the parsed content, depending on the memory usage of the
> latter.



Attachment: pgprTuwB234WW.pgp
Description: PGP signature