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.