We moved here from bug #760520. The thing I'm aiming at here is to add a Condition into the Searches which will tell that it should be related to currently selected messages in the message list.

To be more concrete, the conditions currently are in a form of:

   [ Subject ] [ contains ] [ xxx   ]
   [ Sender  ] [ contains ] [ Milan ]
   [ Follow up ] [ is Flagged ]

and so on. We may add a condition which will explain that it is related to current selection in the message list of the UI, something like:

   [ Selected Messages ]

but I do not know whether it'll be confusing name or not. Thus I'm looking for a good wording. It's similar like [ Match All ] condition.

Your saved search to show only related threads would look like this:

   Find items which match: [ all the following conditions ]
   Include threads: [ All related ]
   [ Selected Messages ]

Which, when being activated, will replace the [ Selected Messages ] with the list of message UIDs in the current folder which are selected in the message list. If it's not applicable, then the condition would result in nothing (like not being there at all).

Thinking of it, I do not see any other usage for it right now. Thus another option is to add a new row to the "Show:" combo box (beside "All Messages" and so on), if we won't find any other usage for this new condition.

As it operates on current selection, it may easily break (like within folder change), which would be easy to "fix" by turning off the filter.

(In reply to Patrick OCallaghan from bug #760520 comment #8)
> I don't have much idea of how to do this (because I realise I
> don't really understand the current syntax, so maybe that needs to be
> explained better), however I'm happy to be a sounding board for ideas.

Do you mean to better describe the Free Form Expression syntax? The current user documentation only references bug #550796 comment #10 (its very end has very few simple examples of the expression). Writing a user documentation page with that description and a set of (common) examples of the expression would definitely help to all the users. If it is it, better to deal with it in another bug report, filled against User Documentation component, or reopen/extend bug #741299.

(In reply to Milan Crha from comment #1)
> Thinking of it, I do not see any other usage for it right now. Thus another
> option is to add a new row to the "Show:" combo box (beside "All Messages"
> and so on), if we won't find any other usage for this new condition.
> 
> As it operates on current selection, it may easily break (like within folder
> change), which would be easy to "fix" by turning off the filter.

If this is the only usage, it might be better to achieve the result a different way without all the complication of new syntax. The effect I'm looking for could be called Show Message Thread and would show (but not select) only messages from the current folder in the current thread.

> (In reply to Patrick OCallaghan from bug #760520 comment #8)
> > I don't have much idea of how to do this (because I realise I
> > don't really understand the current syntax, so maybe that needs to be
> > explained better), however I'm happy to be a sounding board for ideas.
> 
> Do you mean to better describe the Free Form Expression syntax? The current
> user documentation only references bug #550796 comment #10 (its very end has
> very few simple examples of the expression). Writing a user documentation
> page with that description and a set of (common) examples of the expression
> would definitely help to all the users. If it is it, better to deal with it
> in another bug report, filled against User Documentation component, or
> reopen/extend bug #741299.

I did mean that, though fixing it would mean essentially rewriting it. I'll consider filing a separate report for that.

(In reply to Patrick OCallaghan from comment #2)
> If this is the only usage, ...

That's what I do not know. I didn't find any other usage for it, but it doesn't mean much, because I could easily overlook something. If you also cannot think of any other usage for a filter (to use selection from the message list in the filter), then it's okay and only the option to the Show: part could be added.

> The effect I'm looking for could be called Show Message Thread

The "Show Message Thread" sounds good to me.

(In reply to Milan Crha from comment #3)
> (In reply to Patrick OCallaghan from comment #2)
> > If this is the only usage, ...
> 
> That's what I do not know. I didn't find any other usage for it, but it
> doesn't mean much, because I could easily overlook something. If you also
> cannot think of any other usage for a filter (to use selection from the
> message list in the filter), then it's okay and only the option to the Show:
> part could be added.
> 
> > The effect I'm looking for could be called Show Message Thread
> 
> The "Show Message Thread" sounds good to me.

Personally it's pretty much all what I would use it for, so by all means do it that way and avoid the extra costs in developer time, more potential bugs etc. Greater flexibility is nice but it's not free and if there's no demand ...

I added the option into the Show combo named "Message Thread", which is consistent with the other names there.

Please note that this option is very specific, it's not a static filter like all the other options, thus it can "break" easily. The filter remembers selected messages from the time when it was chosen the first time and forgets them as soon as other filter is selected. If you call it when no message is selected, then nothing is shown in the message list. If you call it with multiple messages selected, then threads for all the selected messages are shown. If you switch to another folder, then the list of selected UIDs is forgotten, thus returning back to the previous folder will have 'Message Thread' preselected, but nothing will be shown in the message list. The selection is forgotten even if the other folder had selected the 'Message Thread' option. The chosen UIDs are not saved to the disk, thus closing the evolution and reopening will also cause empty message list.

I can change the behaviour in any aspect, if you consider it too confusing, though all the reason for this is that the filter is not being a static filter, but a dynamic filter driven by the user selection in the message list.

Created commit a4bea5c in evo master (3.19.90+)

Thanks Milan. It sounds good but I'll have to try it of course, and that will probably not happen till version 20 is released. I look forward to testing it.