~jeffrom

https://jeffrom.co

hullo

Recent activity

Re: [PATCH] downstream: fix interface type panic for xirc.MembershipSet 26 days ago

From Jeff Martin to ~emersion/soju-dev

after sending this, i noticed that the issue is actually that sometimes
entry is a pointer, other times a value. sorry for the spam.

On 22/06/05 01:18PM, Jeff Martin wrote:
> ---
> noticed this when deploying HEAD today
>  downstream.go | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/downstream.go b/downstream.go
> index 26032eb..4992546 100644
> --- a/downstream.go
> +++ b/downstream.go
> @@ -3331,8 +3331,8 @@ func sendNames(dc *downstreamConn, ch *upstreamChannel) {

[PATCH] downstream: fix interface type panic for xirc.MembershipSet 26 days ago

From Jeff Martin to ~emersion/soju-dev

---
noticed this when deploying HEAD today
 downstream.go | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/downstream.go b/downstream.go
index 26032eb..4992546 100644
--- a/downstream.go
+++ b/downstream.go
@@ -3331,8 +3331,8 @@ func sendNames(dc *downstreamConn, ch *upstreamChannel) {
	var members []string
	for _, entry := range ch.Members.innerMap {
		nick := entry.originalKey
		memberships := entry.value.(*xirc.MembershipSet)
[message trimmed]

[PATCH] handle message unknown charset error 1 year, 10 months ago

From Jeff Martin to ~sircmpwn/aerc

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.

Thanks to the folks who exposed IsUnknownCharset in emersion/go-message!
---
[message trimmed]

[PATCH v2] improvement: log panic stacktrace 1 year, 10 months ago

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]

[PATCH] improvement: log panic stacktrace 1 year, 10 months ago

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]

[PATCH aerc v2] test(message): fixture harness for MessageInfo 1 year, 11 months ago

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]

[PATCH] test(message): fixture harness for MessageInfo 1 year, 11 months ago

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]