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

Re: mutt/2201: wish: <view-attach> a message/rfc822 applies $display_filter



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

From: "Luis A. Florit" <mutt-bugs@xxxxxxxxxxxxxxxxxxxxxx>
To: bug-any@xxxxxxxxxxxxx
Cc: 
Subject: Re: mutt/2201: wish: <view-attach> a message/rfc822 applies 
$display_filter
Date: Sun, 11 Jun 2006 00:17:06 -0300

 * El 06/06/06 a las 14:42, Alain Bench chamullaba:
 
 >  On Sunday, June 4, 2006 at 22:15:02 +0200, Luis A. Florit wrote:
 > 
 > > Sorry for sending an email
 > 
 > No worries: That's the intended way for reporters to followup on
 > their bug. Such mails are recorded in the BTS and forwarded to
 > mutt-dev. Note: I read mutt-dev, so CCing me is useless (as
 > indicated by my MFT).
 > 
 > OTOS responders by mail to bug-any@bmo should not CC mutt-dev
 > (duplication), but should CC the reporter and other interested
 > parties not reading mutt-dev. Unfortunately MFT doesn't help that.
 > 
 > Responses thru the BTS website itself automatically go to mutt-dev,
 > the reporter, and any additional interested parties.
  
 Ok.
  
 > > For me the script works very well
 > 
 > No. The script is unreliable. Depending on fields order, suite, and
 > spelling, it strips too much or not enough, matches wrong positives
 > in header and in body, and sometimes happens to strip the empty line
 > separating header and body. Completely FUBAR.
 
 Sorry, I wasn't clear enough. 
 The script is not just FUBAR: it is a complete suicide!!!
 
 I didn't try to say that the script was a good one, 
 but that it showed that there was a (supposedly) bug. 
 Don't be afraid, I don't use that as a script to strip headers. 
 A good script to do so cannot be a one line script.
 
 > The difference you see between complete and weeded headers is only
 > an effect of the script brokenness, and of its unwanted sensitivity
 > to fields sequence. Example: Pipe a full header where "Cc:"
 > immediatly follows "To:", both multiline. The To is stripped, but
 > not the Cc.
  
 Not really the problem, but you were right, it was 
 a mistake in the script that was responsible for this: 
 I have the 'To:' header as the first one in 'hdr_order'.
 And '^' does not match for the beginning of line in perl IF
 the line is the first one! Stupid me, sorry!! 50 lashes here.
 
 > > trying to guess what mutt was doing (adding tabs or something like
 > > that)
 > 
 > Weeding doesn't change the filter input, outside of the removal of
 > ignored fields, and reordering of the remaining ones by hdr_order.
 
 Exactly because of this reordering of the headers the problem arose. 
  
 > > * El 04/06/06 a las 18:13, Alain Bench chamullaba:
 > > > wish to make use of $display_filter in attachments menu.
 > > I would prefer to call it a bug because it is inconsistent.
 > 
 > Agreed: I'll change severity. 
 
 Ok.
 
 > What means "chamullaba"?
 
 Would you believe if I tell you that you're
 the first person in a year that asked?? 
 
 It is a funny Argentinian slang, that means "said".
 Just a silly thing.
 
 > > mutt shows for the mutt-users [digest]
 > > |   I     2 <no description>      [multipa/digest, 8bit, 26K]
 > > |   I     3 |->200605/478        [message/rfc822, 8bit, 2.5K]
 > > These numbers '2000605' are useless. It would be much better if the
 > > subject is shown (like with vim mailing list).
 > 
 > I never saw an MJ2 digest, but would guess that those parts have a
 > "Content-Description: YYYYMM/NNN" field, that the %d expando
 > (_%d_escription) in $attach_format is intended to display,
 > in priority to the embedded "Subject:".
 
 Exactly! Good.
 And it seems that I can do nothing to correct this by only
 using mutt... (of course I can play with my .procmailrc).
  
 >  On Sunday, June 4, 2006 at 23:25:01 +0200, Nicolas Rachinsky wrote:
 > 
 > > > make use of $display_filter in attachments menu.
 > > > Only for message/rfc822, or also for text/* parts?
 > > I think it should only used for message/rfc822, I don't think it's
 > > that useful for other text parts. And the filter would have to
 > > recognize wether it's used for an arbitrary text or for an mail if
 > > it's used to manipulate the headers.
 > 
 > Hum... OTOS some kind of simple filters (rot13, removal of ^M, or
 > such) do not care about header/body. Users may expect they apply
 > to text parts also.
  
 Yes, you're right.
  
     Thanks for your patience!
 
         Luis.