I've added auto-updating for old VF rules, so the main element of this 
ticket has been completed.

BC is *not* given with this format.  It would require complex 
retooling of both current virtual folder rules and development of a 
new, internal format to save the rules.  This is much more than a 
trivial change.



It is a worthy goal, just not one that appears appropriate for IMP 
4.2.  Moving to another ticket.

Changes have been made in CVS for this ticket:

http://cvs.horde.org/diff.php/imp/lib/Search.php?r1=1.37.10.42&r2=1.37.10.43&ty=u
http://cvs.horde.org/diff.php/imp/locale/en_US/help.xml?r1=1.53.6.13&r2=1.53.6.14&ty=u
http://cvs.horde.org/diff.php/imp/search.php?r1=2.128.2.29&r2=2.128.2.30&ty=u
http://cvs.horde.org/diff.php/imp/templates/search/search.html?r1=1.28.2.2&r2=1.28.2.3&ty=u

Changes have been made in CVS for this ticket:

http://cvs.horde.org/diff.php/imp/lib/Search.php?r1=1.114&r2=1.115&ty=u
http://cvs.horde.org/diff.php/imp/search.php?r1=2.197&r2=2.198&ty=u

Just read my earlier post again and think I should clarify the 
relation between the different versions of search:
The order I gave represents the usefulness (in my eyes!) of the 
original search, Michael´s patched search, and my proposed search, not 
their expressiveness.



Michael´s patched version describes a set of searches not completely 
covering the original, so no backward compatibility. However, it has 
increased usability by exhibiting a better comprehensibility for the 
users.



The proposed version is a superset of both the original and the 
Michael´s, so backward compatibility is given (once the save format is 
handled), although it has a slightly more complex GUI. For me, it is a 
good trade-off between expressiveness and usability.



I vote for my version ;o)) But I would be happy with Michael´s version 
as well, which is a clean approach seen in many mail clients. I just 
tested current CVS and everything works well.
Yes, fixed. Talking about enhancements, may I suggest to delete empty 
search fields from this display (and storage): they are unnecessary 
clustering the string with, e.g., "To for ´´ in INBOX", and new 
searches have a lot of empty fields to offer quick access to the 
different header fields.





   Martin

I like the idea of automatically detecting old-style rules, and 
converting them on the fly to the new format.

The new code fixes it. So it would be great if the changes could be 
separated into bugfix and whatever is backwards incompatible.

uh, haven't found that discussion ...
Yes, indeed.
I do not propose to allow arbitrary nesting/parentheses, as the GUI 
would become very complex (drag and drop for some indention pops into 
my mind). You pointed this out as well. However, if you have two fixed 
and, therefore, only three logical operators, the GUI should not be 
too complicated:



Search Criteria (O OR  X AND)

     Criteria 1

     Criteria 2

     Criteria 3



X  Match Criteria AND Flags

O  Match Criteria OR  Flags



Search Flags (O OR  X AND)

     Flag 1

     Flag 2

     Flag 3



(with O unselected and X default option)



This GUI keeps up the differentiation between Criteria and Flags, 
which, in general, is fine for me. It does not allow every logic 
combination of sub-searches, but a lot more than before: the set of 
new searches would be a real superset of the current searches and the 
searches possible with your or-patches.



I do not know about elegance, and I do not know whether everybody 
finds this GUI as intuitive as I do. Furthermore, I cannot say that 
this proposed GUI is the non-plus-ultra (free nesting would be), but 
IMHO(!) it is much superior to the current and to your patched 
version. Ordering them would give for me:



     (and/or) and (and)   <    and/or    <   (and/or) and/or (and/or)   
   <    ??
For already saved searches in "old" format (making trouble for your 
patches as you mentioned), using the X-selection as default for 2nd 
and 3rd operator would keep up the old behavior. Just saving the 
searches in new format if changed, or writing a little upgrade script 
for the DB should be easy.



I do wait with smoke-testing your already provided patches until I get 
feedback to this proposal. If you reject it, I'll go with your 
patches, as saved searches are not a problem for my users.





ad "flagged for followup": ack, forget what I said.

Thinking about this a second... this is going to break virtual folders 
with flags, so it is doubtful that this is something that can go into 
IMP 4.2.

I can't reproduce this, but it could be because the new code fixes or 
it could be because I don't understand what you are trying to say here.

yes.
With my recent changes, it should now be possible to do this.
This is what I have done - I have moved the search flags into the 
search criteria.  Please test and check for smoke, etc.
This was talked about long ago but isn't easily done - how do you 
"lump" queries together?  For example, how do I specify that I want (A 
AND B) OR (C AND D) - the result must contain A/B pairs or C/D pairs - 
not (A AND B OR C) AND D - the result must contain D and must contain 
either A/B pair or C.  In other words, nobody has come up with an 
elegant way of making the UI handle 'parentheses' so, thus, the reason 
we have either all AND or all OR searches.
This has been fixed as a result of the new code (since it pretty much 
uses the same code previously used for the search criteria).
I don't understand what this is saying.  There is no "important" IMAP 
flag, only a "flagged for followup" flag.

Changes have been made in CVS for this ticket:

   http://cvs.horde.org/diff.php/imp/lib/Search.php?r1=1.113&r2=1.114&ty=u
   http://cvs.horde.org/diff.php/imp/search.php?r1=2.196&r2=2.197&ty=u
   
http://cvs.horde.org/diff.php/imp/templates/search/search.html?r1=1.29&r2=1.30&ty=u

Though it doesn't seem to. Michael, it looks like if the only criteria 
you choose are flags, the search doesn't match anything, whether it's 
an AND or an OR search.

Why not? A "match any" query, with multiple flags, should work fine...

testing IMP 4.2 with most of the other current modules. Am I correct 
that searches are built by one of the following two modes?



All Queries: AND( AND(CRIT_1, CRIT_2, ...) AND(FLAG_1, FLAG_2, ...) )

Any Queries: AND(  OR(CRIT_1, CRIT_2, ...) AND(FLAG_1, FLAG_2, ...) )





My understanding is that it is not possible to do imap searches for 
OR-combination of flags, correct? (e.g. all new OR unanswered messages).



That could be fixed by making "search flags" on par with the "search 
criteria", i.e. applying the all/any-switch to flags as well. Even 
better: provide three all/any-switches for search criteria, search 
flags and their combination:



AND/OR(  AND/OR(crit_1, crit_2, ...), AND/OR(FLAG_1, FLAG_2, ...) )



That would enormously extend the space of possible searches by still 
avoiding a complex GUI for the general nesting of logical operators.







Furthermore two little glitches in the current GUI:

  - In "recent searches", the flags are not mentioned.

  - "Search Flags" for all the imap flags, but "flagged message"

    for only the important flag.





Martin