Search for messages of threads I participated in

[Tassilo Horn]

Hi all,

is there a way I can search for messages of threads I participated in?
Basically, that would mean that a message of mine (query
"contact:my-add") can be reached by following the References: header
recursively.

Right now, I have bookmarks like

"flag:unread AND (contact:my-adr1 OR contact:my-adr2 OR ...)"

which captures unread messages where I'm involved but that falls short
on mailinglists where not everybody replying to a message of mine adds a
courtesy Cc to myself. In that case, I frequently miss important mails
because they don't stand out in my "flag:unread" search which I check
after the "unread and I'm a contact" search from above.

Back in my Gnus days, I've solved that with adaptive scoring where I
scored up messages I've read (a tiny amount for each read message) and
scored up my own messages (a huge amount) and then sorted threads by
total score (and then by date). So here, the threads here I've
participated where always on top, then the threads which were at least
interesting enough that I've read messages from them, and then the
boring stuff.

Bye,
Tassilo

[Dirk-Jan C. Binnema]

I'd probably use "flag:unread AND flag:personal" and include related
results (mu4e-search-include-related).

Kind regards,
Dirk.


--
Dirk-Jan C. Binnema Helsinki, Finland
e:dj...@djcbsoftware.nl w:www.djcbsoftware.nl
gpg: 6987 9CED 1745 9375 0F14 DA98 11DD FEA9 DCC4 A036

[Tassilo Horn]

"Dirk-Jan C. Binnema" <dj...@djcbsoftware.nl> writes:

Hi Dirk,

> I'd probably use "flag:unread AND flag:personal" and include related
> results (mu4e-search-include-related).

Ah, flag:personal is good and seems to be the same as my generated
(contact:addr1 OR contact:addr2 OR ...) cascade.

However, the above is not quite what I want. Ideally, I'd search for
"flag:personal" with mu4e-search-include-related [1] and then filter
that search's results with "flag:unread".

Bye,
Tassilo

[1] BTW, is it possible to specify the properties like
"Include-related", "Full search", "Show threads", "Skip duplicates", and
"Hide-predicate" directly in a query? That would be useful for
bookmarks where for one bookmark you might like to have different props
than for another one.

[Dirk-Jan C. Binnema]

On Sunday Jul 21 2024, Tassilo Horn wrote:

> "Dirk-Jan C. Binnema" <dj...@djcbsoftware.nl> writes:
>
> Hi Dirk,
>
>> I'd probably use "flag:unread AND flag:personal" and include related
>> results (mu4e-search-include-related).
>
> Ah, flag:personal is good and seems to be the same as my generated
> (contact:addr1 OR contact:addr2 OR ...) cascade.

Yeah, you do need to specify your addresses at mu-init time
(--my-address) for that though, for obvious reasons. It is more
efficient too.

> However, the above is not quite what I want. Ideally, I'd search for
> "flag:personal" with mu4e-search-include-related [1] and then filter
> that search's results with "flag:unread".
>
> Bye,
> Tassilo
>
> [1] BTW, is it possible to specify the properties like
> "Include-related", "Full search", "Show threads", "Skip duplicates", and
> "Hide-predicate" directly in a query? That would be useful for
> bookmarks where for one bookmark you might like to have different props
> than for another one.

You can influence those properties indeed, through mu4e-search-hook and
mu4e-search-bookmark-hook. mu4e-headers-hide-predicate can be useful as
well, perhaps in combination with those hooks.

Should be possible to get what you want that way.

[Tassilo Horn]

"Dirk-Jan C. Binnema" <dj...@djcbsoftware.nl> writes:

>> Ah, flag:personal is good and seems to be the same as my generated
>> (contact:addr1 OR contact:addr2 OR ...) cascade.
>
> Yeah, you do need to specify your addresses at mu-init time
> (--my-address) for that though, for obvious reasons.

I do that.

>> [1] BTW, is it possible to specify the properties like
>> "Include-related", "Full search", "Show threads", "Skip duplicates",
>> and "Hide-predicate" directly in a query? That would be useful for
>> bookmarks where for one bookmark you might like to have different
>> props than for another one.
>
> You can influence those properties indeed, through mu4e-search-hook
> and mu4e-search-bookmark-hook. mu4e-headers-hide-predicate can be
> useful as well, perhaps in combination with those hooks.

So basically, I would invent a new query keyword "!RELATED_AND_UNREAD!"
which would result in setting

(setq mu4e-search-include-related t)
(setq mu4e-search-hide-predicate
(lambda (msg)
(member 'unread (mu4e-message-field msg :flags))))

in mu4e-search-hook if it's in the query and then remove that custom
keyword again in mu4e-query-rewrite-function? Do you mean something
like that?

The issue I see with that approach is that it modifies global variables
so one needs to make sure that they get reset to my "default values for
general use". Or maybe not... What buffer is current when
mu4e-search-hook is run? Already the new, not yet populated headers
buffer? If that were the case, one could probably just use setq-local
and be done.

Bye,
Tassilo

[Dirk-Jan C. Binnema]

Hi Tassilo,

On Tuesday Jul 23 2024, Tassilo Horn wrote:

> "Dirk-Jan C. Binnema" <dj...@djcbsoftware.nl> writes:
>
>>> Ah, flag:personal is good and seems to be the same as my generated
>>> (contact:addr1 OR contact:addr2 OR ...) cascade.
>>
>> Yeah, you do need to specify your addresses at mu-init time
>> (--my-address) for that though, for obvious reasons.
>
> I do that.
>
>>> [1] BTW, is it possible to specify the properties like
>>> "Include-related", "Full search", "Show threads", "Skip duplicates",
>>> and "Hide-predicate" directly in a query? That would be useful for
>>> bookmarks where for one bookmark you might like to have different
>>> props than for another one.
>>
>> You can influence those properties indeed, through mu4e-search-hook
>> and mu4e-search-bookmark-hook. mu4e-headers-hide-predicate can be
>> useful as well, perhaps in combination with those hooks.
>
> So basically, I would invent a new query keyword "!RELATED_AND_UNREAD!"
> which would result in setting
>
> (setq mu4e-search-include-related t)
> (setq mu4e-search-hide-predicate
> (lambda (msg)
> (member 'unread (mu4e-message-field msg :flags))))
>
> in mu4e-search-hook if it's in the query and then remove that custom
> keyword again in mu4e-query-rewrite-function? Do you mean something
> like that?

That's one way, but you could use those hooks I mentioned; i.e., for
mu4e-search-hook

have some (cond (...)) for the various queries for which you need
non-default settings for mu4e-search-include-related etc., with the 'all
the rest' clause with your default settings.

> The issue I see with that approach is that it modifies global variables
> so one needs to make sure that they get reset to my "default values for
> general use". Or maybe not... What buffer is current when
> mu4e-search-hook is run? Already the new, not yet populated headers
> buffer? If that were the case, one could probably just use setq-local
> and be done.

Yeah, once would like to let-bind these things but that's not so easy to
do due to the way mu4e works; the hook runs before we submit the query
to the mu-server and we get the results back asynchronously.

I guess it'd be useful to associate search-parameters directly with
bookmarked-queries and then apply them when showing the results; but
that's something for the future. So for now, the little manual work is
needed.

[Tassilo Horn]

"Dirk-Jan C. Binnema" <dj...@djcbsoftware.nl> writes:

Hi Dirk,

>>> You can influence those properties indeed, through mu4e-search-hook
>>> and mu4e-search-bookmark-hook. mu4e-headers-hide-predicate can be
>>> useful as well, perhaps in combination with those hooks.
>>
>> So basically, I would invent a new query keyword
>> "!RELATED_AND_UNREAD!" which would result in setting
>>
>> (setq mu4e-search-include-related t)
>> (setq mu4e-search-hide-predicate
>> (lambda (msg)
>> (member 'unread (mu4e-message-field msg :flags))))
>>
>> in mu4e-search-hook if it's in the query and then remove that custom
>> keyword again in mu4e-query-rewrite-function? Do you mean something
>> like that?
>
> That's one way, but you could use those hooks I mentioned; i.e., for
> mu4e-search-hook
>
> have some (cond (...)) for the various queries for which you need
> non-default settings for mu4e-search-include-related etc., with the
> 'all the rest' clause with your default settings.

That's what I have tried now: I have a new bookmark

(:name "Unread messages of threads with me"
:query "flag:personal !RELATED !HIDE_UNREAD"
:key ?p)

and added this to my config:

--8<---------------cut here---------------start------------->8---
(defun th/mu4e-search-hook--set-props-for-custom-query-keywords (query)
(when (string-match-p "!RELATED" query)
(setq-local mu4e-search-include-related t))
(when (string-match-p "!HIDE_UNREAD" query)
(setq-local mu4e-search-hide-predicate
(lambda (msg)
(not (member 'unread (mu4e-message-field msg :flags)))))))

(add-hook 'mu4e-search-hook
#'th/mu4e-search-hook--set-props-for-custom-query-keywords)

(defun th/mu4e-query-rewrite-function (query)
;; Remove custom keywords which we use to set `mu4e-search-include-related'
;; and `mu4e-search-hide-predicate' in `mu4e-search-hook'.
(setq query (replace-regexp-in-string "!\\(RELATED\\|HIDE_UNREAD\\)"
"" query)))
--8<---------------cut here---------------end--------------->8---

And it works, I just had your reply in that bookmark which goes only to
the mailinglist! And since the mu4e-search-hook runs with the new
headers buffer current, setq-local also works. Excellent!

There's one annoying issue: since I have a mu4e-search-hide-predicate
which hides messages which aren't unread anymore, as soon as I select a
message, it vanishes from the header view. Can I do something about
that?

Thanks,
Tassilo

[Dirk-Jan C. Binnema]

Hi Tassilo,

On Wednesday Jul 24 2024, Tassilo Horn wrote:

<snip>

> And it works, I just had your reply in that bookmark which goes only to
> the mailinglist! And since the mu4e-search-hook runs with the new
> headers buffer current, setq-local also works. Excellent!
>
> There's one annoying issue: since I have a mu4e-search-hide-predicate
> which hides messages which aren't unread anymore, as soon as I select a
> message, it vanishes from the header view. Can I do something about
> that?

Hmmm... perhaps you can use the 'changed' field in your query or in your
hide predicate, i.e., relax the criterion to "unread or changed in the
last 5 min"

[Tassilo Horn]

"Dirk-Jan C. Binnema" <dj...@djcbsoftware.nl> writes:

Hi Dirk,

>> There's one annoying issue: since I have a mu4e-search-hide-predicate
>> which hides messages which aren't unread anymore, as soon as I select
>> a message, it vanishes from the header view. Can I do something
>> about that?
>
> Hmmm... perhaps you can use the 'changed' field in your query or in
> your hide predicate, i.e., relax the criterion to "unread or changed
> in the last 5 min"

I use this right now which works good:

--8<---------------cut here---------------start------------->8---
(defun th/mu4e-headers-found-hook--clear-hide-predicate ()
"Set `mu4e-search-hide-predicate' to nil.
Otherwise, the message might vanish as soon as we select it."
(setq-local mu4e-search-hide-predicate nil))

(add-hook 'mu4e-headers-found-hook
#'th/mu4e-headers-found-hook--clear-hide-predicate)
--8<---------------cut here---------------end--------------->8---

Bye,
Tassilo