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

Re: mutt/316: Indicate in the Index if a file has attachments



The following reply was made to PR mutt/316; it has been noted by GNATS.

From: David Champion <dgc@xxxxxxxxxxxx>
To: bug-any@xxxxxxxxxxxxx
Cc: Mutt Developers <mutt-dev@xxxxxxxx>
Subject: Re: mutt/316: Indicate in the Index if a file has attachments
Date: Sun, 7 Aug 2005 18:04:40 -0500

 * 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