Open Bug 547589 Opened 14 years ago Updated 2 years ago

Attachment reminder keywords should allow regular expressions

Categories

(Thunderbird :: Mail Window Front End, enhancement)

enhancement

Tracking

(Not tracked)

People

(Reporter: nanotube, Unassigned)

References

(Blocks 1 open bug)

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6
Build Identifier: 

Currently attachment reminder keywords only allow plain text entries, and treats each entry for searching the message as "\Wentrytext\W". 

While this hits many common-use cases, using regexps within expressions can make the filter even smarter. 

Some examples, in no particular order of importance:

1. multiword filters, such as "here it is" are not robust to inclusion of extra spaces between words, which may happen. e.g., try typing "here it  is" and the reminder isn't triggered.

2. verbs require multiple entries to take care of endings, nouns require at least two to account for plural and singular. consider: current-default filters include "attach", "attachment", "attached", and "attaching" - 4 separate keywords where an "attach\w*" would do. seems like you can deal with just separate verb endings fine - but having to do that for everything quickly bloats the filter list. e.g., the default filter list includes "enclosed", but ideally would also include "enclosing" and "enclose"; all nouns need to come with separate singular and plural (there's another entry - "attachments")... in other words, regexps would greatly reduce the clutter from such repetitive entries. 

3. neato tricks with lookbehinds and lookaheads: we can avoid matching when you send someone an email like "hey, you did not attach the file. maybe you should enable the cool thunderbird attachment reminder next time". possible with regexp, by sticking in a negative lookbehind for 'not ' and a negative lookahead for ' reminder', completely impossible with plain text keywords.

4. any number of other patterns that users can figure out individually based on their personal idiosyncrasies as to what they say when they tend to include attachments may be well served with a regexp.

The old thunderbird2 attachment reminder extension used to allow regexp support, and i've had a few users inquire after a port to thunderbird3, just for the regexps... 

to avoid complicating the interface for users who don't know anything about regular expressions, i can suggest having two "types" of keywords, the "regular" ones, and the "regexp" ones, with the regular ones being default. on the "add keyword" dialog, there would be a checkbox saying "this keyword includes regular expressions", which a user may check and then be able to enter full a full regexp into the box that would be properly interpreted. 

Reproducible: Always

Steps to Reproduce:
1. go to attachment reminder keywords preferences
2. try to enter a regular expression as a keyword
3. observe that it gets taken literally
4. bemoan your fate
Actual Results:  
no capability to use regexp in filter keywords. fate bemoaned.

Expected Results:  
see nice "use regexp" checkbox when adding/editing a keyword. use. rejoice.

applies to the latest thunderbird release, 3.0.1 as of this writing.
Status: UNCONFIRMED → NEW
Component: Preferences → Mail Window Front End
Ever confirmed: true
QA Contact: preferences → front-end
The regular-expression syntax is neat for users who know it, but may pose a steep learning curve for those who don't. In addition or as an alternative to regexp syntax, maybe add a more simpler wild-card mechanism (e.g., bash-like "attach{ed,ment,ing}"), which should be more intuitive. Either mechanism would also allow better matching of recognized file extensions, only needing a single entry for each group of associated file names (bug 633818 comment #3).
Or better, we could stem the words (http://en.wikipedia.org/wiki/Stemming) to get more natural search results without requiring users to know Unix shell globbing or regular expressions.

(Yeah, I like my bike sheds yellow, why do you ask?  ;)
See Also: → 1201273
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.