Re: mutt/316: Indicate in the Index if a file has attachments
* On 2005.08.07, in <E1E1tQ6-0001P6-BW@xxxxxxxxxxxxxxxxxxxx>,
* "Brendan Cully" <brendan@xxxxxxxxxx> wrote:
>
> I have no problem with it. In fact I'd love it to work with IMAP too,
> as long as it didn't have to suck down the entire message to parse the
> MIME structure. But I have the impression that tlr has some objections
> to it, so I'm leaving it to him to comment on or commit...
I think tlr's objection to the current patch is precisely that it parses
the MIME structure, and for that it needs the whole message. So I agree
it's not a suitable thing to do for IMAP messages. :) (But as always, if
you don't use the feature, it won't cost you.)
IIRC, it's possible to get IMAP to return a parsed-out representation of
the MIME structure. I don't recall how, but it seems vaguely familiar.
It would be a nice feature add for a later version of the patch. But a
message parse is still going to be needed for local messages, so I think
Thomas's objection is still in play.
Well, I'll start things off here, rather than burdening others with what
I've already thought about.
The "minimal case" I imagine is simply parsing the top-level
Content-type: to determine whether there's multipart content, and
storing that boolean attribute in the HEADER. You can get some effects
now with "~h Content-type:.*multipart", but adding this in code would
make it possible to have (for example) a boolean ~X pattern and %?X?&?
condition which indicates whether there exists multipart content. From
there it's possible to actually put a small symbol on lines that have
multipart content, meeting the commonest request in this vein. And
nothing new would need to be parsed.
With that in place, the current attachment patch would simply extend
the ~X and %X functionality with full message-parsing capability.
--
-D. dgc@xxxxxxxxxxxx NSIT University of Chicago