This would be handy. For myself, it seems the clickable tabs patch (https://git.sr.ht/~sircmpwn/aerc/commit/3b09c07e7a75feed8a9086b0a9003c2cf3ffea59) has broken text highlighting in the message viewer. (I use st as my terminal emulator.)
This is a bit similar to #213 in that they both deal with executing commands on an empty folder. The top two calls in the crash trace are the same. This is also a problem with the
I wonder if there's a way to fix it so that it catches any command executing on an empty folder instead adding checks to every command individually. (But it's also not a big deal to add those checks, see: https://lists.sr.ht/~sircmpwn/aerc/patches/6506)
Patch sent: https://lists.sr.ht/~sircmpwn/aerc/patches/6506
Patch sent that removes the conditional entirely. My reasoning for this is that there is no other place where the IMAPWorker's seqMap is updated, so the
FetchDirectoryContentsaction needs to happen regardless.
That fixes it for me too.
Not sure what a proper fix should be for it though. From what I can tell it doesn't make a difference if
store.DirInfo.Exists != len(store.Uids). What's causing the crash is the
seqMapin the IMAP worker is not getting updated before
I'm wondering if we can't just use a DNS lookup utility to do this instead of using a database. You can test this using
nslookup. For example, if you were setting up an account from fastmail.com you would run the following lookups:
host -t srv _imaps._tcp.fastmail.com host -t srv _imap._tcp.fastmail.com host -t srv _pop3s._tcp.fastmail.com host -t srv _pop3._tcp.fastmail.com
And get the following back:
_imaps._tcp.fastmail.com has SRV record 0 1 993 imap.fastmail.com _imap._tcp.fastmail.com has SRV record 0 0 0 . _pop3s._tcp.fastmail.com has SRV record 10 1 995 pop.fastmail.com _pop3._tcp.fastmail.com has SRV record 0 0 0 .
Based on the linked spec,
_imapshas a lower priority value than
_pop3s(0 vs 10), so
_imapsis preferred. From this we can populate the target FQDN and port (in this case
imap.fastmail.comand 993) and continue with the setup wizard.
Does that reason test? I'm just going off the specification document.
Hi, I'm interested in fixing this bug, as I've been experiencing this too.
Going off of ~geemili's debug statements, it appears
seqMapis not updated after switching back to the first directory. In my quick glance at the code it seems like
handleFetchDirectoryContents()is what's updating
seqMap. But when I switch from INBOX to another folder and back to INBOX I don't see a third call to
seqMapisn't updated, hence the index out of range error.
Does this seem plausible? This is just my first half hour of looking at the code and a little debugging. I'd love to work on a patch for this but I could use a little guidance on how this worker part of the code works and how these events are handled. Thanks