We made a new type out of go-message/mail.Address without any real reason.
This suddenly made it necessary to convert from one to the other without actually
having any benefit whatsoever.
This commit gets rid of the additional type
This change handles message parse errors by printing the error when the
user tries to view the message. Specifically only handling unknown
charset errors in this patch, but there are many types of invalid
messages that can be handled in this way.
aerc currently leaves certain messages in the msglist in the pending
(spinner) state, and I'm unable to view or modify the message. aerc also
only prints parse errors with message when they are initially loaded.
This UX is a little better, because you can still see the header info
about the message, and if you try to view it, you will see the specific
error.
This allows us to hook into the std libs implementation of parsing related stuff.
For this, we need to get rid of the distinction between a mailbox and a host
to just a single "address" field.
However this is already the common case. All but one users immediately
concatenated the mbox/domain to a single address.
So this in effects makes it simpler for most cases and we simply do the
transformation in the special case.
The data was passed around as a string for some reason, which led to time
precision loss and wrong dates being displayed.
Simply pass the time as is to fix that.
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.
Before, we were using several IMAP-specific concepts to represent
information being displayed in the UI. Factor these structures out of
the IMAP package to make it easier for other backends to provide the
required information.
Before, the information needed to display different parts of the UI was
tightly coupled to the specific messages being sent back and forth to
the backend worker. Separating out a models package allows us to be more
specific about exactly what a backend is able to and required to
provide for the UI.
