Provide search and filter with the option to specify more flag based
conditions.
Use '-x <flag>' to search for messages with a flag (seen, answered,
flagged) and '-X <flag>' to search for messages without a flag.
When message dates failed to parse, the error displayed would try to
include the time object it failed to obtain, which would display as
something like 0001-01-01 00:00:00 UTC, which isn't of much help.
Instead, display the text we were trying to parse into a date, which
makes the problem easier to debug.
More mail flags can now be set, unset, and toggled, not just the
read/seen flag.
This functionality is implemented with a new `:flag` and `:unflag`
command, which are extensions to the matching `:read` and `:unread`
commands, adding support for different flags. In fact, the
`read`/`unread` commands are now recognized aliases to `flag`/`unflag`.
The new commands are also well documented in aerc(1).
The change mostly extends the previous read/unread setting functionality
by adding a selection for the flag to change.
- 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
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.
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.
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.
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
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)
Previously the workers returned a mixture of decoded / encoded parts.
This lead to a whole bunch of issues.
This commit changes the msgviewer and the commands to assume parts to already
be decoded
Me again,
this time fixing encoding of subjects and attachments. It was problem in
IMAP backend. While other backends user MessageInfo() function which
generates MessageInfo decoded via go-message methodes, IMAP worker is
creating MessageInfo directly, so all non-utf8 subjects and filenames
were in raw form.
This patch fixes it. Not sure if we should care about errors (if
DecodeHeader fails it returns raw string back).
>From what I see, this should solve all encoding problem (tested only
IMAP). So, now I can focus on features. ;-)
Have a great weekend!
Leszek
When deleting a message, sometimes FetchDirectoryContents will fire.
FetchDirectoryContents will return a smaller set of UIDs since messages
have been deleted. This operation races with fetching from the seqMap in
client.ExpungeUpdate. Only recreate the seqMap if it can grow so that
messages will continue to be expunged.
Signed-off-by: Kevin Kuehler <keur@xcf.berkeley.edu>
Right now notmuch panics if something goes wrong in the configure event.
This patch checks for that and returns an error instead, so that we can at least
get the UI up and running (and all the other accounts)
The experience will be completely degraded until another configure event occurs.