~benburwell

https://www.benburwell.com

~benburwell/patchall

Last active 11 months ago

~benburwell/test

Last active 1 year, 8 days ago

~benburwell/howtochooseapassword

Last active 1 year, 1 month ago
View more

Recent activity

Re: Users interested in git-lfs support; build caches 4 months ago

From Ben Burwell to ~sircmpwn/sr.ht-discuss

It appears you're already using docker for your build. I didn't look
very closely at what you're doing, but something that might help is to
build a custom docker image that's already set up with your
dependencies, then start your CI build by just pulling the image and
working from there.

I recognize that this isn't quite the same thing as caching
dependencies, but it might help speed up your build in the meantime.

Re: [PATCH] worker/lib/parse: be more tolerant with parsing email addresses 5 months ago

From Ben Burwell to ~sircmpwn/aerc

I was talking about aerc's parseAddressList function in
worker/lib/parse.go, which calls Header.AddressList from emersion's
go-message library, which in turn calls AddressParser.ParseList from the
standard library.

Both the standard library and emersion's go-message are pretty strict in
their adherence to the RFC 5322. Aerc's parseAddressList function is
meant to attempt parsing with go-message, but if an unparsable address
list is found for whatever reason, it should still return something
useful for the UI.

So I think the solution is 2-fold:

1) update aerc's parseAddressList to fix the err == nil check and remove

Re: [PATCH] worker/lib/parse: be more tolerant with parsing email addresses 5 months ago

From Ben Burwell to ~sircmpwn/aerc

On Thu Jan 30, 2020 at 08:53, Simon Ser wrote:
> I think this is already supposed to be handled by parseAddressList.

That is correct.

> if hdr, err := h.Text(key); err == nil && strings.Contains(hdr, "@") {

The strings.Contains also was inverted in
baa70469c3b25e1b937c9c2a9e0b16762a227bca, it should be
!strings.Contains. Which won't actually solve the problem for the
message you're seeing; perhaps we can drop the strings.Contains
altogether.

In any case, parseAddressList is meant to be lenient.

Re: Discussion: Add color configuration 5 months ago

From Ben Burwell to ~sircmpwn/aerc

Awesome! This seems like a reasonable design to me.

Re: [PATCH v2] Contextual UI Configuration 5 months ago

From Ben Burwell to ~sircmpwn/aerc

On Thu Jan 23, 2020 at 13:56, Srivathsan Murali wrote:
> + Adds parsing of contextual ui sections to aerc config.
> + Add GetUiConfig method for AercConfig that is used to get the
>   specialized UI config.
> + Add UiConfig method to AccountView to get specialized UI Config.
> + Modifies Aerc codebase to use specialized UIConfig instead.
> + Adds documentation for Contextual UI Configuration
> ---
> Finaly got time to work on v2 of this patch, made changes according
> to Drew's feedback from the last version.
> Also added subject context to have specific index-format for patches.
>
> Happy new year folks :D

[PATCH] Fix handling of multiple template-dirs 5 months ago

From Ben Burwell to ~sircmpwn/aerc

Before, while the docs stated that template-dirs was a colon-separated
list, a delimiter was not specified in the struct tag, so it was falling
back to the default for the ini library (a comma). Also added a note to
the docs to clarify that templates are configured in the [templates]
section.
---
 config/config.go      | 6 +++---
 doc/aerc-config.5.scd | 4 +++-
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/config/config.go b/config/config.go
index e5f7395..fe548ff 100644
--- a/config/config.go
+++ b/config/config.go
[message trimmed]

Re: [PATCH] imap: emit messageinfo when changing read state. 5 months ago

From Ben Burwell to ~sircmpwn/aerc

On Thu Jan 23, 2020 at 08:17, Reto Brunner wrote:
> -	imapw.worker.PostMessage(&types.Done{types.RespondTo(msg)}, nil)
> +	imapw.worker.PostAction(&types.FetchMessageHeaders{
> +		Uids: msg.Uids,
> +	}, func(msg types.WorkerMessage) {
> +		switch m := msg.(type) {
> +		case *types.Error:
> +			err := fmt.Errorf("handleReadMessages: %v", m.Error)
> +			imapw.worker.Logger.Printf("could not fetch headers: %s", err)
> +			emitErr(err)
> +		case *types.Done:
> +			imapw.worker.PostMessage(&types.Done{types.RespondTo(msg)}, nil)

Note that the msg parameter from the callback is shadowing here, so the

[PATCH] Add docs for reply -T 5 months ago

From Ben Burwell to ~sircmpwn/aerc

---
A minor omission I noticed while preparing the list-reply patch. Since
that series has been nack'd, I'm mailing this one separately. Thanks!

 doc/aerc.1.scd | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/doc/aerc.1.scd b/doc/aerc.1.scd
index 73a4d83..c0e8ad4 100644
--- a/doc/aerc.1.scd
+++ b/doc/aerc.1.scd
@@ -116,13 +116,15 @@ message list, the message in the message viewer, etc).

	*-p*: Pipe just the selected message part, if applicable
[message trimmed]

[PATCH] Strip trailing newline from address book entries without names 5 months ago

From Ben Burwell to ~sircmpwn/aerc

When the list of completions from the external command doesn't have
associated contact names, the email address we attempt to parse was
being terminated with a newline. Now, we strip the trailing newline if
present.
---
 completer/completer.go | 20 +++++++++++---------
 1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/completer/completer.go b/completer/completer.go
index f6900ee..bc6c96f 100644
--- a/completer/completer.go
+++ b/completer/completer.go
@@ -138,16 +138,18 @@ func readCompletions(r io.Reader) ([]string, error) {
			return nil, err
[message trimmed]

Re: [PATCH 1/2] Teach the reply command about mailing lists 6 months ago

From Ben Burwell to ~sircmpwn/aerc

On Mon Jan 6, 2020 at 8:47 AM, Reto wrote:
> Would it make sense to fallback to List-ID and try to parse it as a
> mail address?  Probably not RFC approved, but may be useful for some
> random list that doesn't set the List-Post header?

I would rather not add features that deviate from RFCs until we need
them for a sort of "quirks mode."

> I don't think that we need to (nor should) set all possible
> combinations as keyboard shortcuts. [...] People should set up those
> more "special" ones themselves.

Fair enough -- I was sort of on the fence about including the shortcuts;
I've removed them from v2.