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.

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?

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?

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?

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

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.

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.

This is probably related to #101, since if folders = X,Y and default = X are defined, the crash does not happen. I suggest to close this one in favor of the other.

For both the maildir and the notmuch interfaces, if the account has a folders definition in its config file but default is not defined, aerc crashes.

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