Any thread opening is normally done from a search query. That search
query might have nothing to do with the unread status, and could only
match a handful of messages in the thread. So, rather than jumping to
the first unread message, we keep the search query as context when
opening the thread and use it to jump to the first message matching it.
When tagging a single message in a thread, only refresh that message
rather than the entire thread.
This is again due to some threads being *very* big, which when combined
with crypto signatures make the UI feel sluggish when changing the state
of a message, e.g. when reading it for the first time.
The computing time now doesn't scale with the size of the thread. It's
at similar levels from before on small threads, and is an order of
magnitude better on the recent tmpfs thread on debian-devel.
Note that right now we go through the entire list to get the index of a
given message. This could easily be optimized later on.
This has a really noticeable cost when reading monster threads, e.g. if
you're reading Debian mailing lists. It gets even worse when there's
crypto involved! OTOH, it's fairly unlikely that the data changes
underneath our feet if we're using Dodo to drive the "notmuch new"
calls, as it would trigger a refresh when done (or mark the panel as
dirty).
This allows collating multiple events on the same threads, e.g. reading
a long unread thread in a Thread panel. The previous approach would
trigger a full refresh if reading more than one message.
Updating the entire search panel when touching any piece of data is
really costly, which is presumably why we only do it on the currently
active one and will only refresh the other ones when we focus them.
This patch allows for a more granular approach to refreshes, with an API
that specifies which thread has been updated. Each panel can then either
update their own data model (if known to be relevant, e.g. the thread is
already in the search results, and it is cheap enough to do it right
away), mark itself as dirty to fall back on the previous global
behaviour, or ignore the update entirely (relevant for Thread panels).
When line wrapping in a folded content-disposition header occurs within
its filename parameter value, then the get_filename() method of the
(legacy) email.message.Message object returns a string containing a
newline character at the position where the filename parameter value
wraps. An attachment filename containing a newline character may result
in undefined behaviour with file management tools or scripts and may
have security implication. It also prevents forwarding mail in dodo by
throwing the exception 'Header values may not contain linefeed or
carriage return characters', because the filename is copied in the A:
pseudo-header.
This bug is not present in the email.message.EmailMessage class, which is
used when specifying the policy email.policy.default.
Additionally, the legacy method get_payload() is replaced by
get_content().
Signing and encryption is done on a copy of the original message. When
this original message contained non-ASCII characters, the copy process
introduced encoded words with the unknown-8bit charset.
This simplifies the code as we don't have to copy the data over from the
temporary Message object. The header copying in particular was failing
when using multiline headers as allowed by RFC 822.
I'm guessing we *could* get into trouble with encoding though? Since I'm
using UTF-8 everywhere it works fine for me.
This silences the following warnings in Python 3.12:
dodo/util.py:118: SyntaxWarning: invalid escape sequence '\s'
quoted = re.compile('^\s*>')
dodo/util.py:119: SyntaxWarning: invalid escape sequence '\s'
empty = re.compile('^\s*$')
The actual behaviour doesn't change, as Python inserts the \ when the
escape sequence is invalid (checked on Python 3.12)
I have email in my inbox that use TEXT/PLAIN as a content-type, and
according to https://www.w3.org/Protocols/rfc1341/4_Content-Type.html
that's valid:
> The type, subtype, and parameter names are not case sensitive.
> For example, TEXT, Text, and TeXt are all equivalent
