~zachs


#225 Add option to disable mouse input entirely 4 months ago

Comment by ~zachs on ~sircmpwn/aerc2

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.)

#216 crash on reply with empty inbox/folder 5 months ago

Comment by ~zachs on ~sircmpwn/aerc2

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 :read and :unread commands.

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)

#213 Crash on delete in empty folder 5 months ago

Comment by ~zachs on ~sircmpwn/aerc2

Patch sent: https://lists.sr.ht/~sircmpwn/aerc/patches/6506

#127 panic: runtime error: index out of range in handleFetchMessages 5 months ago

Comment by ~zachs on ~sircmpwn/aerc2

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 FetchDirectoryContents action needs to happen regardless.

https://lists.sr.ht/~sircmpwn/aerc/patches/6437

#127 panic: runtime error: index out of range in handleFetchMessages 5 months ago

Comment by ~zachs on ~sircmpwn/aerc2

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 seqMap in the IMAP worker is not getting updated before handleFetchMessages() is called.

#100 Use SRV records to discover server address 5 months ago

Comment by ~zachs on ~sircmpwn/aerc2

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 host or 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, _imaps has a lower priority value than _pop3s (0 vs 10), so _imaps is preferred. From this we can populate the target FQDN and port (in this case imap.fastmail.com and 993) and continue with the setup wizard.

Does that reason test? I'm just going off the specification document.

#127 panic: runtime error: index out of range in handleFetchMessages 5 months ago

Comment by ~zachs on ~sircmpwn/aerc2

Hi, I'm interested in fixing this bug, as I've been experiencing this too.

Going off of ~geemili's debug statements, it appears seqMap is 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 handleFetchDirectoryContents() so seqMap isn'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