Changing face of unread email

[Alex Bennée]

Hi,

I think since cdd0256664 (mu4e: Show 'related' messages with
mu4e-related-face) unread messages no longer show in an obvious
different colour. Examining the properties this is because they are
tagged as related before tagged as unread. I tried changing the tagging
function order:

(defsubst mu4e~headers-apply-flags (msg fieldval)
"Adjust LINE's face property based on FLAGS."
(let* ((flags (plist-get msg :flags))
(meta (plist-get msg :meta))
(face (cond
((or (memq 'unread flags) (memq 'new flags))
'mu4e-unread-face)
((plist-get meta :related) 'mu4e-related-face)
((memq 'trashed flags) 'mu4e-trashed-face)
((memq 'draft flags) 'mu4e-draft-face)
((memq 'flagged flags) 'mu4e-flagged-face)
((memq 'replied flags) 'mu4e-replied-face)
((memq 'passed flags) 'mu4e-forwarded-face)
(t 'mu4e-header-face))))
(add-face-text-property 0 (length fieldval) face t fieldval)
fieldval))

but it works inconsistently. Is there some sort of caching going on that
means mu4e doesn't recompute the faces for older searches?

Either way I think visually mu4e should prioritise unread over related
as that is what you are usually looking for when checking on threads.

--
Alex Bennée

[Dirk-Jan C. Binnema]

It's something to address for in headers-mode (or its successor) to have
'additive' face properties... personally, I rarely have any unread
messages show up as 'related', but sure perhaps unread could come first.

"Not working consistently", could that perhaps be due to it being a
defsubst rather than a defun? You need to evaluate it as well as its
users (I've run into this a few times).

Note that you can use the "," keybinding to see the message-sexp which
should tell you what flags it has; it should match up with your defsubst
definition.

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

[Alex Bennée]

What is "related" meant to mean anyway? If you are following mailing
list threads they will be related but potentially unread.

> "Not working consistently", could that perhaps be due to it being a
> defsubst rather than a defun? You need to evaluate it as well as its
> users (I've run into this a few times).

Ahh maybe..

>
> Note that you can use the "," keybinding to see the message-sexp which
> should tell you what flags it has; it should match up with your defsubst
> definition.
>
> 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

--
Alex Bennée

[Dirk-Jan C. Binnema]

On Thursday Jun 23 2022, Alex Bennée wrote:

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

>>> Either way I think visually mu4e should prioritise unread over related
>>> as that is what you are usually looking for when checking on threads.
>>
>> It's something to address for in headers-mode (or its successor) to have
>> 'additive' face properties... personally, I rarely have any unread
>> messages show up as 'related', but sure perhaps unread could come
>> first.
>
> What is "related" meant to mean anyway? If you are following mailing
> list threads they will be related but potentially unread.

The "related" messages are a message and all its children, as per the
References: and In-Reply-To: headers.

Kind regards,
Dirk.