Re: [Evolution] "Include threads:" setting for Search Folders?

[Paul Rozdeba <prozdeba physics ucsd edu>]

Thanks for the replies! Yes, that was me on IRC, thanks for your help there too Milan.

So I'm still unsure of the effect of this option. When you replaced "message location" with "sender contains", did you include your own email address and set that as the only search criterion? If so, I'm getting some unexpected behavior here (using a Gmail account) that I think show what the root of the issue is. First, I create a search folder using the criteria:

Find items which match: any of the following conditions

Include threads: All related

Sender contains: <username>@gmail.com

If I choose "All local and active remote folders" as my sources, then the folder shows threads where I am the sender, along with with all related messages from every IMAP folder *except* the Inbox! If I choose to only include <account>: INBOX and <account>: [Gmail]/Sent Mail, then I get a similar result where all I see are messages in my Sent folder. In other words, the search folder seems to ignore the inbox as a source.

I agree with you, Milan, about what the various "Include threads" options should do. However, I think these tests we've done show that, at least, the "all related" option does not have that behavior. I would argue in favor of keeping these options if their behavior could be documented (and I guess acted the way you outlined earlier), because they would be super useful in my use case, and I would imagine a lot of people would want this as well. Giving a similar example to my first one, if I want a folder only showing "active" conversations, it would be great to have this option to show threads containing messages in my inbox, plus any related messages in the rest of my account's folders.

P.s. I think that the "No reply or parent" option would be useful if you wanted (for whatever reason) a folder containing messages that are *not* conversations, i.e. threads you haven't been engaged in or which you did not originate.

Thanks again,

Paul

On Thu, 2017-11-02 at 12:15 +0000, Patrick O'Callaghan wrote:

> On Thu, 2017-11-02 at 12:57 +0100, Milan Crha wrote:
> > On Thu, 2017-11-02 at 10:57 +0000, Patrick O'Callaghan wrote:
> > > The fact that you yourself have to guess how it works would seem to
> > > indicate that it isn't actually specified anywhere.
> >
> > 	Hi,
> > I should find out by the code reading, but I've been lazy. :)
> >
> > On the other hand, once things are less intuitive (or not intuitive at
> > all), then it either means they are complicated (not necessarily
> > powerful) or they use incorrect/vague/... names or descriptions. I mean
> > with that that I tried to guess only based on the names of the options,
> > without code reading (which is something general users hardly do).
> > Having good option names, thus they describe what they do easily, is a
> > plus, though not every option can achieve it. From my point of view.
>
>
> I agree. If the only solution is to read the code, there's something
> wrong. I think in this case the problem is one of conception: it isn't
> clear (or it isn't clear enough) what the behaviour should be. Unless
> that's defined and described, there's no hope of getting it right.
>
> poc
> _______________________________________________
> evolution-list mailing list
> evolution-list gnome org
> To change your list options or unsubscribe, visit ...
> https://mail.gnome.org/mailman/listinfo/evolution-list