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

Re: [PATCH] For 1.5.12: attachment counting for index display



On Tuesday, 20 September 2005 at 02:26, David Champion wrote:
> I'd really prefer to keep the configurability.  I've found myself using
> it more than once.  But I've always been uncomfortable with having eight
> configuration commands just for attachments, and it's definitely a good
> target.

Ok, reducing that to attachments/unattachments seems like a nice
compromise :) And putting the defaults in the global Muttrc seems fine
too.

>     Attach.6 provides validated attachment-count caching, so it's a
>     lot faster.  There are several elements here.  For one thing, I

cool.

>     %Q expands to a "Q" if a MIME part qualifies.  It can be used as a
>     %?Q?&? condition if you want to display something else.
> 
>     %X expands to the count value for a MIME part and its descendants
>     (if any).  It also can be used conditionally.
...
>     I suspect we could get rid of $attach_recurse and
>     $attach_ignore_fundamental.  I'd be surprised if anyone ever uses
>     "no" for either of these.  Any objections?

It seems sane to get rid of attach_ignore_fundamental. The only reason
to keep attach_recurse is if it makes some noticeable performance
difference. But probably once you've started parsing the message
recurring through it isn't much more work - if that's true,
attach_recurse could go...

>     %Q in $attach_format is really useful, but %X is perhaps not.

my instinct was the reverse, but then I'm not actually using the patch
yet. Might as well keep them both, especially since %X matches up with
the index.

>     Although running the attachment count whenever a message is parsed
>     is, on the whole, a good move, it does mean that there's no way
>     to inhibit the attachment count if you're not using the %X or ~X
>     features.  The attachment count is pretty low overhead in the
>     context of a MIME parse, but still it might be worthwhile to have a
>     way to disable it.  How important is this?

Doesn't seem worth doing. The important thing IMHO is just not to do
any more mime parses than necessary...

> And finally, the kicker: have I just lost all hope of ever getting
> into CVS? :)

If tlr doesn't object too much, I think it's getting very close to
commit-ready... thanks for the code massage.

-b

Attachment: pgpsmR3p1XMII.pgp
Description: PGP signature