~devonrjohnson


#269 EOF Error a month ago

Comment by ~devonrjohnson on ~sircmpwn/aerc2

I have also had this issue occur multiple times on a Linux system. I have not seemed to find any pattern to the issue in terms of content of the email. Only pattern I have had is that it has occurred multiple times sending to one email address. This is also sending from a gmail account.

#286 Visual mode/Mark command 2 months ago

feature added by ~devonrjohnson on ~sircmpwn/aerc2

#286 Visual mode/Mark command 2 months ago

Ticket created by ~devonrjohnson on ~sircmpwn/aerc2

Adding a Visual mode and/or mark command similar in functionality to in Ranger would be extremely useful.

#285 panic: runtime error: index out of range in worker/imap/worker.go 2 months ago

Comment by ~devonrjohnson on ~sircmpwn/aerc2

If it is the same line, I would expect that to be the case. But I am by no means an expert on the code. I just don't know why else the imap worker would need to expunge messages. Hopefully someone with a little more expertise can help debug.

#285 panic: runtime error: index out of range in worker/imap/worker.go 2 months ago

Comment by ~devonrjohnson on ~sircmpwn/aerc2

Do you know if it is the same section of code causing it? Or is it just another index out of range error? I have not been able to completely reliably reproduce the error, I just know it happens in that section of code when deleting chunks of emails from the *client.ExpungeUpdate case in the handleImapUpdate function.

#285 panic: runtime error: index out of range in worker/imap/worker.go 2 months ago

bug added by ~devonrjohnson on ~sircmpwn/aerc2

#285 panic: runtime error: index out of range in worker/imap/worker.go 2 months ago

Ticket created by ~devonrjohnson on ~sircmpwn/aerc2

When deleting a large chunk of emails, often times while working through the deletes, aerc will throw an index out of range error. I pinpointed the offending code to be in worker/imap/worker.go:228-229

i := update.SeqNum - 1
uid := w.seqMap[i]

For some reason the update.SeqNum is much larger than the seqMap length. In one example run, len(w.seqMap) == 7 and i == 23. I would patch myself, but I am not completely sure of the underlying issue and would rather avoid a hacky fix.