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
Go pre 1.15 parsed an empty string as an error, 1.15 did not but this was
unintentional as per https://github.com/golang/go/issues/40803
Fix the comment accordingly
Go 1.15 handles "" in the address parser as a non error case, returning
an empty list.
Prior versions returned an error, which is not what we want.
Reported-by: anianz <a.ziegler@cioplenu.de>
Tested-by: anianz <a.ziegler@cioplenu.de>
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.
If a message date would fail to parse, the worker would never receive
the MessageInfo it asked for, and so it wouldn't display the message.
The problem is the spec for date formats is too lax, so trying to ensure
we can parse every weird date format out there is not a strategy we want
to pursue. On the other hand, preventing the user from reading and
working with a message due to the error format is also not a solution.
The maildir and notmuch workers will now fallback to the internal date, which
is based on the received header if we can't parse the format of the Date header.
The UI will also fallback to the received header whenever the date header can't
be parsed.
This patch is based on the work done by Lyudmil Angelov <lyudmilangelov@gmail.com>
But tries to handle a parsing error a bit more gracefully instead of just returning
the zero date.
Note that, until we get color configuration, this means that the user *must*
have the %Z verb in the index format else it'll be horribly confusing
as no visual indication is provided
This patch sets up the trigger config section of aerc.conf.
Each trigger has its own function which is called from the place where
it is triggered. Currently only the new-email trigger is implemented.
The triggers make use of format strings. For instance, in the new-email
trigger this allows the user to select the trigger command and also the
information extracted from the command and placed into their command.
To actually execute the trigger commands the keypresses are simulated.
Further triggers can be implemented in the future.
Formatting of the command is moved to a new package.
Reto Brunner
Andrew Jeffery
Thorben Günther
Srivathsan Murali