- Add maildir flags to complement a messages imap flags
- Set the "seen" flag on sent messages when using the maildir backend
- Cleanup AppendMessage interface to use models.Flag for both IMAP and
maildir
This changes the ui to show the spinner while we are sorting. It only
shows one line of the spinner since there are an unknown number of
messages at this time.
There was an unused error value as well as unnecessary usage of the sort
interface. There should now be less copying so a bit better performance
in some cases.
Updates to a store can be asynchronous so we shouldn't select it just
because it had an update. Selection of the stores should be driven by
explicit user commands.
This ensures that the directory info is up to date on events in the
maildir worker. This also sets up the initial dirinfo for other
directories and updates them when using built-in commands.
FS events are still only watched for the selected directory. This should
be changed in a future patch to watch other directories too in order to
cover UI updates for folders when an event occurs in a non-selected
folder.
Hi. This adds a template function to convert a time to the local time zone. And modifies
the default quoted_reply template to use it and show the time zone when formatting the
timestamp of the quoted message.
Previously, the quoted message timestamp was UTC and it would format it without the time
zone. And I thought it might be a little confusing or weird to some normal people when I
email them and I don't want normal people to be confused or think that I'm weird.
Apparently sending an event for every incoming messageInfo slows down
the application significantly.
Therefore this slows down the emmision rate, on the cost of being out of date
in some cases.
This fixes an issue with the updated count logic, where only fetched messages
where counted to the exists string of the rue count.
Note that the count is still broken (we only count read / unread messages we
fetched, but that is the same behaviour as prior to the commit
66b68f35b3)
This reverts commit bd4df53009.
I did not properly untangle the opening / dirlist update of each other.
This interferes with the imap worker, hence the revert
Actions such as read / unread or the addition of new messages do change
the read/unread/recent count. Hence we request an update from the workers.
Workers going over the network should probably cache the information and invalidate
it only if necessary
Currently the dirlist ignores the counts provided by the dirInfo.
However some of the workers can actually provide accurate counts much quicker
than if we count the flags.
Eventually we will also want to enable displaying counts for background folders,
where the brute force counting won't work as none of the headers are fetched yet.
This commit models it in an opt-in manner, if the flag isn't set then we still
count the messages manually.
Previously, sending a DirectoryInfo assumed that a directory change
happened. However we don't want that if we only want to update the
unread message count.
The idle restart code is at the end of handleMessage in the worker.
However if an unsupported msg comes in, we returned early, skipping the re-init.
That lead to a crash due to double closing idleStop in the next iteration.
Opening a notmuch DB gives you a snapshot of the stage at that specific time.
Prior to this, we only reopened the DB upon writing.
However, if say a mail sync program like offlineimap is fetching new mail,
we would never pick it up.
This commit caches a db for a while, so that we don't generate too much overhead
and does a reconnect cycle after that.
I hardcoded a value as I don't think that having an option would be beneficial.
Any write operation (meaning reading mail) anyhow flushes the DB by necessity.
(we need to close to commit tag changes, which changing the read state is)
If the message doesn't contain ':', we don't properly discard the
message, so we end up slicing it like msg[:-1].
This can be reproduced if one runs 'aerc foo', as the server receives
'foo' as the message.
'aerc foo' still doesn't do anything very user friendly, but at least it
doesn't panic horribly.
While at it, do the 'got message' log at the very beginning, so that the
user can see what message the server got before reporting the command as
invalid.
Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
