~lyudmil

Recent activity

Re: [PATCH] improve date parsing for notmuch/maildir 5 hours ago

From Lyudmil Angelov to ~sircmpwn/aerc

> @Lyudmil (I hope that's your first name? If not my apologies)

It is my first name :) Thanks for reaching out. Sorry for the late response, I
was on vacation.

> What do you think?

I like this better than the approach I was pursuing. Thank you for working on
it!

> How does this patch work for you?

Works great - I can see the emails I'd received with the improper date format.
Their dates appear as a sequence of question marks.

Re: [PATCH 2/2] Parse dates without time zones 8 days ago

From Lyudmil Angelov to ~sircmpwn/aerc

> What about this:
>
> 1. Always return a zero time.Time when parseDate fails
> 2. Catch parseDate errors in parseEnvelope, push the error so that it's
> displayed to the user (and/or log it) and do not return it there
> 3. When showing the date, check Time.IsZero() and display "invalid"
> instead of a broken time

I've submitted a patch that attempts to do this. The commit message no
longer made sense, so I started a new thread ("Allow working with
messages when their dates cannot be parsed") and annotated it with "v2".
I'm sorry if this is poor etiquette – just let me know and I'll handle
it differently next time.

[PATCH v2] Allow working with messages when their dates cannot be parsed 15 days ago

From Lyudmil Angelov to ~sircmpwn/aerc

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.

We therefore log and display any date parsing errors, but still display
the message. Instead of the broken date, we display repeated dashes to
ensure the message fields stay aligned.
---
This is a follow-up to the following thread:
https://lists.sr.ht/~sircmpwn/aerc/patches/11535
[message trimmed]

Re: [PATCH 1/2] Make it easier to debug date parsing errors 30 days ago

From Lyudmil Angelov to ~sircmpwn/aerc

Hi,

> I've merged the error format patch to master, I think it makes sense to
> change it.

Awesome, thanks!

> However I didn't include the second commit of yours, which adds the
> format
> >"Mon, _2 Jan 2006 15:04:05"
>
> That date format is broken and I'm not sure we really want to have a
> large collection of quirky date formats from some small provider /
> application.

Re: [PATCH 2/2] Parse dates without time zones a month ago

From Lyudmil Angelov to ~sircmpwn/aerc

> ...we use the envelop date [for sorting,] don't we?

I don't know the code well enough, but evidence suggest that's not
what's used for sorting. The reason I say this is that the sort order
doesn't change with or without my current patch. Without the patch the
offending messages won't show, but they remain in the position I expect
them to be in based on when I received them.

Re: [PATCH 2/2] Parse dates without time zones a month ago

From Lyudmil Angelov to ~sircmpwn/aerc

> [Someone has committed to] send a patch to make our date parsing code
> the same as in the imap worker...

I'm not sure this resolves the more fundamental problem, which is that
parseDate seems to be written with the intent never to prevent a
Envelope from being returned out of parseEnvelope. I say this because it
always returns a time.Time, even if it encounters errors. However,
parseEnvelope ignores this and will not return an Envelope if any errors
are encountered with parsing dates.

This makes the flawless execution of parseDate essential for the message
to be displayed, which feels brittle. It looks like the only way to
guarantee parseDate never prevents the user from seeing the message is
to make it so it never returns errors, but making date parsing errors