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: Alain Bench <veronatif@xxxxxxx>
To: bug-any@xxxxxxxxxxxxx
Cc: "Luis A. Florit" <mutt-bugs@xxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: mutt/2201: wish: <view-attach> a message/rfc822 applies
$display_filter
Date: Tue, 6 Jun 2006 14:42:51 +0200 (CEST)
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.
> 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.
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.
> 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.
> * 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. What means "chamullaba"?
> 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:".
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.
Bye! Alain.
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?