bugThe nmh Mail Handling System - Bugs: bug #24640, Strip prefixes from Subject in...

 
 

bug #24640: Strip prefixes from Subject in repl (also sortm, scan)

Submitted by:  Jeffrey C Honig <jchonig>
Submitted on:  Fri 24 Oct 2008 02:38:55 AM UTC  
 
Category: EnhancementSeverity: 3 - Normal
Priority: 5 - NormalStatus: None
Assigned to: NoneOpen/Closed: Open

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Fri 24 Oct 2008 02:43:01 AM UTC, comment #7:

To: -unavailable-
cc: Paul Fox <pgf@foxharp.boston.ma.us>,
nmh workers <nmh-workers@nongnu.org>
Subject: Re: [Nmh-workers] Additional subject prefixes to ignore
In-reply-to: Message from -unavailable- on
Wed, 24 May 2006 21:47:36 -0400.<200605250147.k4P1lbB4006725@turing-police.cc.vt.edu>
References: <20694.1148518425@foxharp.boston.ma.us> <13316.1148519658@mittens.honig.net> <200605250147.k4P1lbB4006725@turing-police.cc.vt.edu>
From: jch
X-Mailer: MH-E 8.0.3+cvs; nmh 1.2; GNU Emacs 22.1.1
Fcc: mail/mh
--------
OK, only 29 months to reply to this one.

This is an interesting idea. Since a resent post reminded me that
implementing something along these lines was warranted, I started
looking at it. First I did a quick version fetching a ``Subject-Re-Regex''
from the profile, i.e.:

Subject-Re-Regex: ^([Rr][Ee]|[Ff][Ww][Dd]?):

And implemented it in repl and sortm (see diff attached).

Now I'm looking at your suggestion and it sounds interesting. The issue
is that mh-format functions can take only one argument. The first
solution I can think of is a function named ``resubject'' which would
apply the specified regular expression to the subject field. How do we
handle RFC2047 subjects? Have two functions resubject and deresubject?

Also, as you alluded to in your example, it would be nice not to assume
that the Re: field is a prefix and allow a regular expression
substitution, not just a match. That would require a method to specify
both the match string and the replacement string, something like perl
uses (the first character is the separator).

This would also leave sortm with a different mechanism.

Another alternative would be to specify the regular expression in the
profile (Regex-Pattern: %match%sub%) and then provide the string as the
argument %(regsub{subject}). This would allow sortm to silently use the
same mechanism.

Anyone have any ideas to contribute?

Thanks (谢谢).

Jeff

(file #16725)

Jeffrey C Honig <jchonig>
Project Member
Fri 24 Oct 2008 02:41:25 AM UTC, comment #6:

Cc: Jon Steinhart <jon@fourwinds.com>, nmh workers <nmh-workers@nongnu.org>
From: Lyndon Nerenberg <lyndon@orthanc.ca>
Subject: Re: [Nmh-workers] Additional subject prefixes to ignore
Date: Wed, 24 May 2006 20:16:18 -0700
To: Jeffrey C Honig <jch@honig.net>

On May 24, 2006, at 7:59 PM, Jeffrey C Honig wrote:

> 1) If we start requiring regex, we need to fix configure. Will this
> limit systems nmh can run on? Do we support systems that do not
> have
> POSIX regex?


Shoot configure and write to POSIX. There's nothing MH needs that
cannot be accommodated by the POSIX standard.

--lyndon

Jeffrey C Honig <jchonig>
Project Member
Fri 24 Oct 2008 02:41:06 AM UTC, comment #5:

To: Jon Steinhart <jon@fourwinds.com>
cc: nmh workers <nmh-workers@nongnu.org>
Subject: Re: [Nmh-workers] Additional subject prefixes to ignore
From: "Jeffrey C Honig" <jch@honig.net>
Date: Wed, 24 May 2006 22:59:56 -0400
Sender: -unavailable-

Jon Steinhart <jon@fourwinds.com> wrote:

> > I'm hesitant to try to use a regex because the only regex code in nmh is
> > strictly for pick and generalizing it or making it use POSIX regular
> > expressions is more than I want to take on at the moment.
> >
> > Yeah, I'm chicken, I admit it.
>
> The posix regular expression library calls are simple to use.
> It's not like you have to write your own from scratch anymore.


Yeah, that's easy. The hard parts are:

1) If we start requiring regex, we need to fix configure. Will this
limit systems nmh can run on? Do we support systems that do not have
POSIX regex?

2) If we add some code that uses POSIX regex, we should update pick to
be consistent. Does the code in picksbr use the same syntax as the
POSIX code?

3) This is going from a two hour enhancement to a multi-day enhancement
and cleanup.

Thanks.

Jeff

Jeffrey C Honig <jchonig>
Project Member
Fri 24 Oct 2008 02:40:42 AM UTC, comment #4:

To: nmh workers <nmh-workers@nongnu.org>
Subject: Re: [Nmh-workers] Additional subject prefixes to ignore
Comments: In-reply-to "Jeffrey C Honig" <jch@honig.net>
message dated "Wed, 24 May 2006 21:14:18 -0400."
Date: Wed, 24 May 2006 19:48:53 -0700
From: Jon Steinhart <jon@fourwinds.com>
Sender: nmh-workers-bounces+jch=honig.net@nongnu.org

> I'm hesitant to try to use a regex because the only regex code in nmh is
> strictly for pick and generalizing it or making it use POSIX regular
> expressions is more than I want to take on at the moment.
>
> Yeah, I'm chicken, I admit it.


The posix regular expression library calls are simple to use.
It's not like you have to write your own from scratch anymore.

Jon

Jeffrey C Honig <jchonig>
Project Member
Fri 24 Oct 2008 02:40:04 AM UTC, comment #3:

To: Jeffrey C Honig <jch@honig.net>
Cc: Paul Fox <pgf@foxharp.boston.ma.us>, nmh workers <nmh-workers@nongnu.org>
Subject: Re: [Nmh-workers] Additional subject prefixes to ignore
From: -unavailable-
Date: Wed, 24 May 2006 21:47:36 -0400

On Wed, 24 May 2006 21:14:18 EDT, Jeffrey C Honig said:

> That's a good idea. But I think that can be accomplished w/o a regex by
> listing `[listname]' as a prefix to list for each list you are on.
>
> I'm hesitant to try to use a regex because the only regex code in nmh is
> strictly for pick and generalizing it or making it use POSIX regular
> expressions is more than I want to take on at the moment.


On the other hand, generalizing it would be pretty nice, too. Not only
would it be useful for 'sort', but for 'scan' as well, and even things
like 'repl' - using the regexp to trim off so we can re-sane the messy
'Re: FW: [list] re:' noise we see now. Fortunately for scan and repl,
we can do all the heavy lifting in one place, in a filter %regexp of some
sort.

%regexp{pcre,string} - so we'd have:

Subject: Re: %regexp{"([Rr][Ee]:|[Ff][Ww][Dd]:|\[[a-zA-Z-]\])\(\1\)",%{subject}}

Or something like that....

Jeffrey C Honig <jchonig>
Project Member
Fri 24 Oct 2008 02:39:37 AM UTC, comment #2:

To: Paul Fox <pgf@foxharp.boston.ma.us>
cc: "nmh workers" <nmh-workers@nongnu.org>
Subject: Re: [Nmh-workers] Additional subject prefixes to ignore
From: "Jeffrey C Honig" <jch@honig.net>
Date: Wed, 24 May 2006 21:14:18 -0400
Sender: -unavailable-

Paul Fox <pgf@foxharp.boston.ma.us> wrote:

> i think i understand what you're getting at, but i'd like to see it
> be a regular expression that gets trimmed before the sort (i assume
> that's what you're referring to). in particular, i get mail from lists
> which prepend the listname. that coupled with mailers that do and
> don't strip existing "Re:" strings gives subjects that begin with
> any of:
> [listname] foo
> Re: [listname] foo
> [listname] Re: foo
> Re: [listname] Re: foo
>
> (i realize that an expression that catches these risks corrupting
> a valid subject. so far, i'm willing to risk that.)


That's a good idea. But I think that can be accomplished w/o a regex by
listing `[listname]' as a prefix to list for each list you are on.

I'm hesitant to try to use a regex because the only regex code in nmh is
strictly for pick and generalizing it or making it use POSIX regular
expressions is more than I want to take on at the moment.

Yeah, I'm chicken, I admit it.

Thanks.

Jeff

Jeffrey C Honig <jchonig>
Project Member
Fri 24 Oct 2008 02:39:18 AM UTC, comment #1:

To: "nmh workers" <nmh-workers@nongnu.org>
Subject: Re: [Nmh-workers] Additional subject prefixes to ignore
Date: Wed, 24 May 2006 20:53:45 -0400
From: Paul Fox <pgf@foxharp.boston.ma.us>
Sender: nmh-workers-bounces+jch=honig.net@nongnu.org

jeffrey c honig wrote:
> I have to deal with mail from Outbreak, I mean Outlook, on a daily
> basis. At least I get paid for the privilege...
>
> Much of this mail comes with a subject prefix of FW: instead of Re:.
> This messes up sorting by subject.
>
> I would like to train nmh to string FW: in addition to Re:. But that
> seems like too specific a solution to the problem. A more general
> solution would be to add flags to the relevant commands to add prefixes
> to the list.

i think i understand what you're getting at, but i'd like to see it
be a regular expression that gets trimmed before the sort (i assume
that's what you're referring to). in particular, i get mail from lists
which prepend the listname. that coupled with mailers that do and
don't strip existing "Re:" strings gives subjects that begin with
any of:
[listname] foo
Re: [listname] foo
[listname] Re: foo
Re: [listname] Re: foo

(i realize that an expression that catches these risks corrupting
a valid subject. so far, i'm willing to risk that.)

paul
=---------------------
paul fox, -unavailable- (arlington, ma, where it's 50.7 degrees)

Jeffrey C Honig <jchonig>
Project Member
Fri 24 Oct 2008 02:38:55 AM UTC, original submission:

Moving mail thread into a bug:

To: "nmh workers" <nmh-workers@nongnu.org>
Subject: Additional subject prefixes to ignore
From: "Jeffrey C Honig" <jch@honig.net>
Date: Wed, 24 May 2006 20:43:41 -0400
Sender: -unavailable-

I have to deal with mail from Outbreak, I mean Outlook, on a daily
basis. At least I get paid for the privilege...

Much of this mail comes with a subject prefix of FW: instead of Re:.
This messes up sorting by subject.

I would like to train nmh to string FW: in addition to Re:. But that
seems like too specific a solution to the problem. A more general
solution would be to add flags to the relevant commands to add prefixes
to the list.

The relevant places are in uip/sortm.c, uip/replsubr.c and
uip/msgcmds.c.

In order not to conflict with -subject in sortm I propose a flag of
-sprefix to append to the list and possibly -nosprefix to reset the list
(to just re:).

Comments?

Thanks.

Jeff

Jeffrey C Honig <jchonig>
Project Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

Attached Files
file #16732:  diff added by jchonig (4kB - application/octet-stream - How about a diff for code that has actually been tested)
file #16725:  diff added by jchonig (4kB - application/octet-stream)

 

Depends on the following items: None found

Digest:
   bug dependencies.

 

Carbon-Copy List
  • -unavailable- added by pm215 (Updated the item)
  • -unavailable- added by jchonig (Submitted the item)
  •  

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 4 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Wed 19 Dec 2012 12:30:19 AM UTClevineDependencies-=>bugs #15272 is dependent
    Mon 29 Dec 2008 10:06:07 PM UTCpm215Categoryuser interface=>Enhancement
    Fri 24 Oct 2008 06:57:53 PM UTCjchonigAttached File-=>Added diff, #16732
    Fri 24 Oct 2008 02:43:01 AM UTCjchonigAttached File-=>Added diff, #16725

    Back to the top


    Powered by Savane 3.1-cleanup