From Jeff Martin to ~sircmpwn/aerc
Write panic error and stacktrace to the apps logger. Panics that occur while the ui is running leave the terminal in a garbled state, making it difficult to read the stacktrace. The app log is the logical place to write it. --- wups, shadowed err in the last patch -_- aerc.go | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/aerc.go b/aerc.go index 17b3c57..964d6bf 100644 --- a/aerc.go +++ b/aerc.go [message trimmed]
From Jeff Martin to ~sircmpwn/aerc
Write panic error and stacktrace to the apps logger. Panics that occur while the ui is running leave the terminal in a garbled state, making it difficult to read the stacktrace. The app log is the logical place to write it. --- aerc.go | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/aerc.go b/aerc.go index 17b3c57..41e30b5 100644 --- a/aerc.go +++ b/aerc.go @@ -6,6 +6,7 @@ import ( "io/ioutil" [message trimmed]
From Jeff Martin to ~sircmpwn/aerc
This change introduces a fixture-based test runner with the eventual
goal of testing against a corpus of desired RFC5322 messages.
I noticed aerc leaves certain messages in the list in the pending "[..]"
state, and I'm unable to view or modify the message. Mostly these
messages are spam, but some are from what I assume are old and
misconfigured mail clients, and other MUAs handle them fine. This patch
provides a simple tool to leave breadcrumbs, provide a debugging aid,
and easy reproducibility for discovered edge cases.
Amended to better signal the intent of the test interface; these
fixtures should all be handled by aerc in some way (without an error).
If desired, fixtures for unresolved issues can be added and executed
via:
[message trimmed]
From Jeff Martin to ~sircmpwn/aerc
This change introduces a fixture-based test runner with the eventual
goal of testing against a corpus of desired RFC5322 messages.
I made this CR because I noticed aerc leaves certain messages in the
list in the pending "[..]" state, and I'm unable to view or modify the
message. Mostly these messages are spam, but some are from what I assume
are old and misconfigured mail clients, and other MUAs handle them fine.
So it seems useful to have a test suite like this, if for no other
reason than to better define the types of messages aerc wont bother with.
Gathered these fixtures from
https://docs.python.org/3/library/email.examples.html and
https://github.com/jstedfast/MimeKit.
---
[message trimmed]