Comment by ~inwit on ~rjarry/aerc
About "Decide if we need FS watchers for deleted/moved messages": if the user relies on mbsync through a system service, aerc can show an outdated message list, so I'd say yes.
Comment by ~inwit on ~rjarry/aerc
Update: the errors are reproduced upon events like activating threads, receiving a new email, opening a message, reloading the folder... In those cases, aerc is still responsive while the errors are being dumped to the log, but CPU goes to 100% during the process. Opening a message should not trigger a re-read of the folder, should it?
Comment by ~inwit on ~rjarry/aerc
Or maybe those 26s are what it takes for reading the whole set of messages, and would not be reduced if there were no wrongly specified messages?
Ticket created by ~inwit on ~rjarry/aerc
When showing a maildir folder, if some messages do not adhere to the proper RFC2822 specification, aerc is slowed down, while showing error messages as, for example:
ERROR 2022/12/12 19:22:11.546359 worker.go:466: could not get message info: mail: missing '<' in msg-id ERROR 2022/12/12 19:22:11.231045 worker.go:466: could not get message info: mail: missing '@' in msg-id ERROR 2022/12/12 19:18:56.914947 worker.go:466: could not get message info: mail: invalid string
In a maildir account replicated from Gmail using offmap, of a total of >200k messages, I have around 4k messages that trigger those errors. When opening the "all mail" folder, aerc takes quite a lot of time, and the logs says that it is spending over 26s while reporting those errors.
Would it be possible to deal with wrongly specified messages more gracefully?
Ticket created by ~inwit on ~rjarry/aerc
Especially in the notmuch+maildir interface, it would be nice to have a means to access the files in the maildir folder structure that represent a given message. This information could be shown in the headers of the message view, for example, or in a pop-up like the envelope's.
It would be even nicer to be able to operate on those single files (deleting all but one of them comes to mind).
Ticket created by ~inwit on ~rjarry/aerc
On current master, if you have 3 messages and delete the 2nd one, the message is removed from the list. However, if you move the cursor from message 1 to 3, or viceversa, the cursor disappears and you need to move it again to make it arrive to the desired message. It's as if the cursor was navigating over the deleted message.
In other words, messages are properly evacuated after deletion or move, but only apparently: when you move the cursor over the place where deleted messages were, it disappears for as many messages as you have ve deleted.
Ticket created by ~inwit on ~rjarry/aerc
The message list behaves weirdly after these steps: 1) load a notmuch+maildir account, 2) go to a big folder, 3) deactivate threading and activate it again.
Now, if one moves down the message list, everything works fine until aerc seems to try to load more messages. At that point, aerc takes a while and then, when it shows more messages, some of them are missing (just blank) and cursor becomes chaotic when scrolling up or down, as it randomly jumps from message to message with no clear pattern.
Comment by ~inwit on ~rjarry/aerc
This is probably related to #101, since if
folders = X,Y
anddefault = X
are defined, the crash does not happen. I suggest to close this one in favor of the other.
Ticket created by ~inwit on ~rjarry/aerc
For both the maildir and the notmuch interfaces, if the account has a
folders
definition in its config file butdefault
is not defined, aerc crashes.
Ticket created by ~inwit on ~rjarry/aerc
In the notmuch+maildir client, if I define
folders = X,Y
where X is a maildir folder and Y is a query defined in the query map, aerc crashes when entering notmuch's tab. Here's the log:panic: runtime error: slice bounds out of range [:-1] [recovered] panic: runtime error: slice bounds out of range [:-1] goroutine 1 [running]: git.sr.ht/~rjarry/aerc/logging.PanicHandler() git.sr.ht/~rjarry/aerc/logging/panic-logger.go:51 +0x73e panic({0xa920e0, 0xc003716588}) runtime/panic.go:844 +0x258 git.sr.ht/~rjarry/aerc/widgets.(*DirectoryTree).Draw(0xc00032a5a0, 0xc003702ba0) git.sr.ht/~rjarry/aerc/widgets/dirtree.go:69 +0xafd git.sr.ht/~rjarry/aerc/lib/ui.(*Bordered).Draw(0xc00034cda0, 0xc003702b70) git.sr.ht/~rjarry/aerc/lib/ui/borders.go:69 +0x415 git.sr.ht/~rjarry/aerc/lib/ui.(*Grid).Draw(0xc0001c0f30, 0xc003702b40) git.sr.ht/~rjarry/aerc/lib/ui/grid.go:126 +0x21b git.sr.ht/~rjarry/aerc/widgets.(*AccountView).Draw(0xc0003581a0, 0xc003702b40) git.sr.ht/~rjarry/aerc/widgets/account.go:163 +0x65 git.sr.ht/~rjarry/aerc/lib/ui.(*TabContent).Draw(0xc000326850, 0xc003702b40) git.sr.ht/~rjarry/aerc/lib/ui/tab.go:456 +0x22f git.sr.ht/~rjarry/aerc/lib/ui.(*Grid).Draw(0xc0001c0900, 0xc0003940c0) git.sr.ht/~rjarry/aerc/lib/ui/grid.go:126 +0x21b git.sr.ht/~rjarry/aerc/widgets.(*Aerc).Draw(0xc00033c000, 0xc0003940c0) git.sr.ht/~rjarry/aerc/widgets/aerc.go:175 +0x1cf git.sr.ht/~rjarry/aerc/lib/ui.(*UI).Render(0xc0000a0000) git.sr.ht/~rjarry/aerc/lib/ui/ui.go:109 +0x63 main.main() git.sr.ht/~rjarry/aerc/aerc.go:258 +0xa7d