Remove Subject prefixing (when answering/forwarding) possible?

[Ralf Hildebrandt]

I'm using:

# Erase [ext] tags from e-mails
subjectrx '\[ext\] *' '%L%R'

to remove the tag "optically". Is there any way of removing the
Subject: prefix when answering/forwarding?

[Matthias Apitz]

Post by Ralf Hildebrandt
# Erase [ext] tags from e-mails
subjectrx '\[ext\] *' '%L%R'
to remove the tag "optically". Is there any way of removing the
Subject: prefix when answering/forwarding?

How do you configure this exactly in .muttrc? Thanks

matthias

[Todd Zullinger]

Post by Matthias Apitz

Post by Ralf Hildebrandt
# Erase [ext] tags from e-mails
subjectrx '\[ext\] *' '%L%R'
to remove the tag "optically". Is there any way of removing the
Subject: prefix when answering/forwarding?

How do you configure this exactly in .muttrc? Thanks

http://www.mutt.org/doc/manual/#display-munging

subjectrx was added in 1.8.0, it seems.

[Sandro Santilli]

Post by Todd Zullinger
http://www.mutt.org/doc/manual/#display-munging
subjectrx was added in 1.8.0, it seems.

Thanks so much, I've been feeling the need for this for
a long time, finally satisfied :)

--strk;

[Akkana Peck]

Post by Todd Zullinger
http://www.mutt.org/doc/manual/#display-munging
subjectrx was added in 1.8.0, it seems.

That's wonderful! Something I've been wishing for for a long time.

But the example in the manual doesn't work for me in 1.9.3
(on Debian testing, but I think that's back to being normal mutt,
not neomutt, right?). This line in muttrc:
subjectrx '\[[^\]]*\]? *' '%L%R'
changes
"Re: [LongListName] blah blah"
to
"Re: ongListName] blah blah"

In other words, the first * is ignored and it matches only one
character after the open bracket. I've tried replacing the * with
+, with {1,} and with {0,} but none of them work: * and {1,} match
one character while + and {1,} don't match anything and do don't
do any substitution.

The feature is still great, because I don't strictly need the regex
-- I can make explicit matches for the few really long list names
that are causing problems -- but I wonder why the example in the
manual isn't working.

Also, is it possible to escape a quote? I have one set of emails
that come through with an apostrophe, like
Subject: [Don't care about this super long list ID] blah blah

Escaping within single quotes, like this:
subjectrx 'Don\'t care about this super long list ID]' '%LDONT%R'
gives an "about: unknown command" error.

The workaround of using double quotes works fine:
subjectrx "Don't care about this super long list ID]" '%LDONT%R'
Just curious, since the workaround is fine for now.

...Akkana

[Christian Ebert]

* Akkana Peck on Wednesday, February 28, 2018 at 09:28:41 -0700

Post by Akkana Peck

Post by Todd Zullinger
http://www.mutt.org/doc/manual/#display-munging
subjectrx was added in 1.8.0, it seems.

That's wonderful! Something I've been wishing for for a long time.
But the example in the manual doesn't work for me in 1.9.3
(on Debian testing, but I think that's back to being normal mutt,
subjectrx '\[[^\]]*\]? *' '%L%R'

I don't understand why the right bracket is backslash escaped
inside the character group in the example.

Post by Akkana Peck
changes
"Re: [LongListName] blah blah"
to
"Re: ongListName] blah blah"

Omitting the escape seems to work for me[tm]:

subjectrx '\[[^]]*\]:? *' '%L%R'

[Patrick Shanahan]

Post by Akkana Peck

Post by Todd Zullinger
http://www.mutt.org/doc/manual/#display-munging
subjectrx was added in 1.8.0, it seems.

That's wonderful! Something I've been wishing for for a long time.
But the example in the manual doesn't work for me in 1.9.3
(on Debian testing, but I think that's back to being normal mutt,
subjectrx '\[[^\]]*\]? *' '%L%R'
changes
"Re: [LongListName] blah blah"
to
"Re: ongListName] blah blah"
In other words, the first * is ignored and it matches only one
character after the open bracket. I've tried replacing the * with
+, with {1,} and with {0,} but none of them work: * and {1,} match
one character while + and {1,} don't match anything and do don't
do any substitution.
The feature is still great, because I don't strictly need the regex
-- I can make explicit matches for the few really long list names
that are causing problems -- but I wonder why the example in the
manual isn't working.
Also, is it possible to escape a quote? I have one set of emails
that come through with an apostrophe, like
Subject: [Don't care about this super long list ID] blah blah
subjectrx 'Don\'t care about this super long list ID]' '%LDONT%R'
gives an "about: unknown command" error.
subjectrx "Don't care about this super long list ID]" '%LDONT%R'
Just curious, since the workaround is fine for now.

some time ago, in an earlier age, Sven Guckes posted a sed or perl filter
to hide "Subject:" additions, but I seem to have lost it, and he seems to
be missing too :^(

[Christian Ebert]

* Patrick Shanahan on Wednesday, February 28, 2018 at 12:10:59 -0500

Post by Patrick Shanahan
some time ago, in an earlier age, Sven Guckes posted a sed or perl filter
to hide "Subject:" additions, but I seem to have lost it, and he seems to
be missing too :^(

Something like

sed -e '1,/^$/ s/^Subject: *\(Re: *\)*\[[^]]*\] */Subject: \1/'

extended?

But displayfilter have no effect for the index, and I believe
that's what subjectrx is for.

For replying/forwarding an editor script (vim in Sven's case).

[Ian Zimmerman]

Post by Patrick Shanahan
some time ago, in an earlier age, Sven Guckes posted a sed or perl
filter to hide "Subject:" additions, but I seem to have lost it, and
he seems to be missing too :^(

Here's what I do now as part of my incoming pipeline. Of course, this
in fact _rewrites_ the email, not being just a filter for mutt display,
so it's not really what the OP is asking for.

$main::mail is a Mail::Audit instance constructed earlier in the
framework.

## <<15-degunk.pl

use Email::MIME::RFC2047::Decoder ;
use Email::MIME::RFC2047::Encoder ;

my $decoder = Email::MIME::RFC2047::Decoder->new;
my @encparms = (encoding => 'utf-8', method => 'Q');
my $encoder = Email::MIME::RFC2047::Encoder->new(@encparms);
my $tagre = qr{\[[-_?a-zA-Z0-9/]+(\s+(list|forum|spam)|[?])?\]:?}i;
my $repre = qr{(re|fwd):}i;

my $subject = $main::mail->get('subject');

SUBJECT:
{
do {
last SUBJECT unless $subject;
my $subject_dec = $decoder->decode_text($subject);
my $is_reply = 0;
my $prefixed = 0;
while ($subject_dec =~ /^($tagre|$repre)\h*/) {
my $preflen = $+[0];
$prefixed = 1;
$is_reply = 1 if $subject_dec =~ m(^$repre)i;
$subject_dec = substr $subject_dec, $preflen;
}
last SUBJECT unless $prefixed;
$subject_dec = 'Re: ' . $subject_dec if $is_reply;
my $subject_enc = $encoder->encode_text($subject_dec);

$main::mail->add_header('X-Old-Subject' => $subject);
$main::mail->replace_header('Subject' => $subject_enc);
last SUBJECT;
} while 1;
}

## >>15-degunk.pl

[Erik Christiansen]

Post by Patrick Shanahan
some time ago, in an earlier age, Sven Guckes posted a sed or perl filter
to hide "Subject:" additions, but I seem to have lost it, and he seems to
be missing too :^(

The following has served for so many years in my .procmailrc that I
can't recall if it was Sven who provided the method for _stripping_ that
cruft from the incoming subject header.

:0
* ^TO_luv-***@.*luv.asn.au
{
# We need the subject line _content_, minus [list-name]:

SUBJECT=`formail -czX "Subject:" | sed -re "s/Subject:// ; s/ \[luv-[a-z]*\]//g"`

# Header filter leaves body alone:
:0fhw
| formail -i "Subject: $SUBJECT"

# Delivery, with lockfile:
:0:
luv-main
}

The second sed regex could perhaps be generalised, rather than just
retargeted for your problem list, but a quick fix is a good fix, so
long as it does the job, I figure.

Changing "-i" to -I" on line 10 stops the received subject header being
retained as "Old-Subject:", but retaining it is a reminder that the post
has been trivially munged.

The ^TO_ on line 2 accepts either "To:" or "Cc:", as adjunct to simple
duplicates management via formail. (Forces "courtesy copy" to the list
mailbox.)

Erik

[Kevin J. McCarthy]

Post by Akkana Peck

Post by Todd Zullinger
http://www.mutt.org/doc/manual/#display-munging
subjectrx was added in 1.8.0, it seems.

That's wonderful! Something I've been wishing for for a long time.
But the example in the manual doesn't work for me in 1.9.3
(on Debian testing, but I think that's back to being normal mutt,
subjectrx '\[[^\]]*\]? *' '%L%R'

Looks like the example might be wrong in the manual, unless there are
regexp library differences. Because ']' is first in the character
class (after the negation), it shouldn't need to be escaped. This works
for me:
subjectrx '\[[^]]*\]:? *' '%L%R'

If that works for you all, I'll fix up the manual example.

Thanks!

[Matthias Apitz]

Post by Kevin J. McCarthy
Looks like the example might be wrong in the manual, unless there are
regexp library differences. Because ']' is first in the character
class (after the negation), it shouldn't need to be escaped. This works
subjectrx '\[[^]]*\]:? *' '%L%R'
If that works for you all, I'll fix up the manual example.

The man page for muttrc should be checked/fixed to. On 1.8.0 I saw no
hint about 'subjectrx'.

Thanks

matthias

[Kevin J. McCarthy]

Post by Matthias Apitz

Post by Kevin J. McCarthy
Looks like the example might be wrong in the manual, unless there are
regexp library differences. Because ']' is first in the character
class (after the negation), it shouldn't need to be escaped. This works
subjectrx '\[[^]]*\]:? *' '%L%R'
If that works for you all, I'll fix up the manual example.

The man page for muttrc should be checked/fixed to. On 1.8.0 I saw no
hint about 'subjectrx'.

Thanks Matthias, I'll fix that up. Also, my apologies Christian for
obliviously repeating what you had already pointed out as the problem.

[Akkana Peck]

Post by Kevin J. McCarthy

But the example in the manual doesn't work for me in 1.9.3 [ ... ]
subjectrx '\[[^\]]*\]? *' '%L%R'

Looks like the example might be wrong in the manual, unless there are
regexp library differences. Because ']' is first in the character
class (after the negation), it shouldn't need to be escaped. This works
subjectrx '\[[^]]*\]:? *' '%L%R'
If that works for you all, I'll fix up the manual example.

That works for me. Thanks, Kevin and Christian! Great feature.

...Akkana

[Cameron Simpson]

Post by Ralf Hildebrandt
# Erase [ext] tags from e-mails
subjectrx '\[ext\] *' '%L%R'
to remove the tag "optically". Is there any way of removing the
Subject: prefix when answering/forwarding?

Can't speak for forwarding, but in principle you could set your editor to a
script that preedited the compose file then ran your real editor.

My muttrc has:

macro index g "<sync-mailbox>:set editor=muttedit<enter><group-reply>:set editor=$EDITOR<enter>" "group reply"

and "muttedit" is a personal shell script which does some stuff before finally
invoking the editor.

Cheers,
Cameron Simpson <***@cskk.id.au> (formerly ***@zip.com.au)