a panic is caught when launching aerc from a small terminal that can't fit the entirety of a deprecation warning's text.

https://paste.sr.ht/~akspecs/baf5c22966665e67ad09d2242bdc1b8d740969be

meanwhile, From:name appears to work when searching for a lowercase first name.
this is despite one of the suggested searches containing an all lowercase from:me example.

example: https://lists.sr.ht/~delthas/senpai-dev?search=from%3Atim

any other combination of cases will work -- e.g. Tim, tIm, tiM, tIM, etc ...

~akspecs Can you verify if this problem still exists for you?

url to commit e50ab59 https://git.sr.ht/~rjarry/aerc/commit/e50ab5928475ef44e880e3391e5ca164c8077ce4

there is a noticeable delay when switching from message to message while in view mode within a sorted mailbox folder with :prev or :next (J or K with default keybindings).

this delay did not exist prior to e50ab5928475 ('sort: keep sort criteria applied to folder')

expected behaviour: load :next or :prev message quickly with the maildir backend.

problem: messages take as long and sometimes longer to load than with the imap backend.

steps to reproduce: use the maildir backend with a default unsorted config, run :sort (e.g. :sort -r date), view a message and attempt to view the next messages with :next (J).

there is no delay when attempting this on an unsorted maildir.

url to commit c2f4404f https://git.sr.ht/~rjarry/aerc/commit/c2f4404fca15be37228545b1893f5fa335168337

commit c2f4404f 'threading: enable filtering of server-side threads', introduces an inconsistent and awkward behaviour to ':filter -u'.

one can run ':filter -u' with the imap backend, read or mark a message read, and still have the same message in the list of filtered messages until the same filter is applied again. this allows for one to also perform another action to the message (e.g. move / copy / archive). this behaviour was the same before, and after the mentioned commit.

with the maildir backend, another behaviour is observed: running the same ':filter -u' will appear to awkwardly [0] perform live updates to the initial filtered results based on whether the messages still match the initial filter criteria. messages that are (marked) read will no longer appear in the list of filtered messages. one does not have the opportunity to perform an action to the message once it is read like they would have if they were using the imap backend.

"awkward" demonstration: [0]: https://asciinema.org/a/MmWSaQrpIFxpBb2whg9TlFtcU

commit d7feb56 'fix panic on closing a tab' is causing another panic on closing a tab.

there is more than one way to reproduce the issue. here is one approach:

1. launch an up to date dev build (or a build that includes d7feb56)
2. open an email
3. open another tab (e.g. ctrl+t for a terminal tab)
4. go back to the prior tab with ctrl+p
5. close it
6. crash

without d7feb56 this bug cannot be reproduced with these steps.

panic: runtime error: index out of range [7] with length 7 [recovered]
	panic: runtime error: index out of range [7] with length 7

goroutine 1 [running]:
git.sr.ht/~rjarry/aerc/logging.PanicHandler()
	git.sr.ht/~rjarry/aerc/logging/panic-logger.go:47 +0x6de
panic({0xa69c00, 0xc00043e1c8})
	runtime/panic.go:844 +0x258
git.sr.ht/~rjarry/aerc/lib/ui.(*TabContent).Draw(0xc000440930?, 0xc00027f0e0?)
	git.sr.ht/~rjarry/aerc/lib/ui/tab.go:403 +0x145
git.sr.ht/~rjarry/aerc/lib/ui.(*Grid).Draw(0xc000150630, 0xc00019e2a0)
	git.sr.ht/~rjarry/aerc/lib/ui/grid.go:148 +0x2ff
git.sr.ht/~rjarry/aerc/widgets.(*Aerc).Draw(0xc00044a000, 0xc00019e2a0)
	git.sr.ht/~rjarry/aerc/widgets/aerc.go:182 +0x2e
git.sr.ht/~rjarry/aerc/lib/ui.(*UI).Tick(0xc0001800f0)
	git.sr.ht/~rjarry/aerc/lib/ui/ui.go:116 +0x1f7
main.main()
	git.sr.ht/~rjarry/aerc/aerc.go:228 +0xb74

another (maybe) relevant thread: https://lists.sr.ht/~sircmpwn/sr.ht-discuss/%3CBX12ZKOE0SET.2ZM6ZN3ILJJ9F%40homura%3E