@mail/search

[GoogleCodeExporter]

I dont know if this was an intentional behavior... But one can do @mail 
*player... to see a list of messages by that player in their PRIMARY mail 
folder... In all cases I have tested... this primary folder is generally 
folder 0.. even if you set it to folder 1. The problem is... This same 
behavior does not work for alternate folders... or I dont know the proper 
syntax. I have even tried looking at the help file... this behavior is not 
documented.

This brings me to the @mail/search suggestion. I propose we have the ability 
to search for a specific message pattern... utilizing regexp. This search 
would compare results from EVERY aspect of the message from the sender, 
title, body, flags, status, and even a range of dates the message was sent.

Original issue reported on code.google.com by adk...@drigon.com on 15 Aug 2009 at 4:42

[GoogleCodeExporter]

Mike pointed out that the @mail *player is infact documented in help @mail. I 
was 
checking in help mail-reading.

Original comment by adk...@drigon.com on 15 Aug 2009 at 6:53

[GoogleCodeExporter]

Original comment by mike@keyboardzombie.com on 17 Aug 2009 at 3:37

• Changed state: New

[GoogleCodeExporter]

There also seems to be an issue where you cannot specify the folder where to 
search
in: IE: @mail 1:*sketch -> MAIL: Invalid message specification. 

Original comment by adk...@drigon.com on 3 Apr 2010 at 3:10

[GoogleCodeExporter]

+2 for either changing all searches to act on the current folder (yay less 
work), or
+1 for allowing <folder>: before any search spec.

Original comment by mike@keyboardzombie.com on 3 Apr 2010 at 5:40

• Changed state: Accepted

[GoogleCodeExporter]

I vote for the first option... changing all searches to act on the current 
folder

Original comment by adk...@drigon.com on 4 Apr 2010 at 3:57

[GoogleCodeExporter]

In extmail.c, parse_msglist(), the initialization of ms->flags should be 
M_FOLDER, rather than M_MSUNREAD.  I think this is a bug and M_FOLDER was 
originally intended.

It does not appear that the M_MSUNREAD flag is ever even checked later.  This 
change would cause all <msglist> options (player names, message age, and 
message numbers/ranges without the folder prefix, to be checked on the current 
folder.

As written, the msglist parser only looks at one option (specifying a folder is 
part of the message number code but no others).

Expanding the msglist parser to take multiple options and/or regexp search is a 
lot more work.

Original comment by widdis@gmail.com on 10 Jun 2010 at 5:52

[GoogleCodeExporter]

And here's a function to do @mail/search.  I only did a single argument 
(wildcard) version (e.g., @mail/search *foo*) which works on the current 
folder.  Adding the switches to command.c, cmds.c, and SWITCHES is left as an 
exercise for the reader.

Original comment by widdis@gmail.com on 11 Jun 2010 at 6:09

Attachments:

• mailsearch.txt

[GoogleCodeExporter]

Having experimented with a few directions to go, I'm thinking a two-stage 
approach to extending the @mail/search from comment 7.

Step 1 (easy):  @mail/search <text>=<msglist>

This would allow for searching for (wildcard) text in the same group of 
messages you would normally choose with the other msglist options (age, sender, 
folder & message # restrictions, etc.)  

Step 2 (hard):  Expand the <msglist> parser to handle more than one option.  
Currently it only does one of folder:message#, sender, age, or a flag.  Would 
be nice to be able to do more than one, using boolean logic.  However, this 
step would also improve the plain ol' @mail <msg-list> variant as well.

Object now or be stuck with whatever I come up with. :)

Original comment by widdis@gmail.com on 11 Jun 2010 at 7:30

[GoogleCodeExporter]

Patch attached.  Comments:

1. Re: comment 6, the M_MSUNREAD is actually needed. Adding | M_FOLDER solves 
the "current folder" bug noted in OP.  This bit must also be removed when the 
folder is specified in the msglist.  The patch updates parse_msglist to fix 
this.

2. @mail/review and @mail/retract code from Issue 24 is included in this patch. 
 However, all that is needed for @mail/search is the do_mail_search function, 
appropriate calling command switches, and the fixes to parse_msglist.

Suggested helpfile:
MAIL-SEARCHING

  @mail/search <pattern>
        Searches mail in current folder for subject or body matching <pattern>.

  @mail/search <pattern>=<msglist>
        Searches mail in <msglist> for subject or body matching <pattern>.

  The <pattern> is case-insensitive and can include wildcards.

Original comment by widdis@gmail.com on 11 Jun 2010 at 9:52

Attachments:

• mailpatch.txt

[GoogleCodeExporter]

Since recent changes to extmail.c make the patch in comment 9 no longer patch 
cleanly, I'm resubmitting the recommended changes, but separating them into 
pieces so the devs can consider each one independently.

This attachment is a "bugfix" patch of extmail.c's parse_msglist function to 
have @mail listing commands operate on the current folder instead of folder 0.  
Necessary parts are adding the current folder bit "| M_FOLDER" to the default 
flags, and removing that bit in the case where another folder is explicitly 
specified.  The two other instances of M_FOLDER are made redundant by the 
default.

Original comment by widdis@gmail.com on 1 Sep 2010 at 11:16

Attachments:

• mailcurfolder.txt

[GoogleCodeExporter]

And, here's the mail search patch.  (Auto-generated switch files removed from 
the diff.)

Helpfile in comment 9.  One change that might be considered is to switch the 
order of <pattern> and <msglist> in the 2-arg syntax.

Original comment by widdis@gmail.com on 2 Sep 2010 at 12:04

Attachments:

• mailsearch.txt

[GoogleCodeExporter]

Committed the bugfix portion (from comment 10). Haven't committed the new 
functionality, will leave that open to discussion :)

Original comment by mike@keyboardzombie.com on 30 Jan 2011 at 12:53

• Changed state: New

[GoogleCodeExporter]

This issue was closed by revision r1268.

Original comment by mike@keyboardzombie.com on 16 Nov 2011 at 8:39

• Changed state: Fixed

[GoogleCodeExporter]

Err, woops - that was issue 24, not this one.

Original comment by mike@keyboardzombie.com on 16 Nov 2011 at 8:40

• Changed state: New

[GoogleCodeExporter]

bump

Original comment by pandoramush4201 on 25 Mar 2014 at 6:17

[shawnw]

Added the folder change, mail search planned for the database restructure described in #1195