No, it's not exactly reversed. It's just some other order that's different from my query-map file, I can't immediately see what the ordering based on.

Thanks ~rjarry, I can confirm that the list stays unchanged now in my config.

But there's another thing: it's reversed now compared to the order in query-map. Is there an unintended reverse applied to the list somewhere?

The version I use:

$ aerc  -v
aerc 0.15.1 +notmuch (go1.20.4 amd64 linux)

Steps to reproduce:

1. Set up a notmuch account.

2. Set

   query-map = …
   enable-folders-sort = false
   

   for it.

3. Open Aerc and navigate through your folders up and down.

Observed behavior: the folders list in the sidebar jumps randomly almost each time you change directory. Expected behavior: the folder list stays unchanged (in the order in which query-map defines the folders).

It makes sense now, thanks for clarifying!

There are basically only two benefits we'd have by loading the config: we'd get saved queries and we'd get excluded tags. I'm not sure if people would prefer doing that or not.

One argument for doing this is that multiple programs that use notmuch as a backend will have the same view of it. Say, if a Neomutt + Notmuch user is just trying out Aerc + Notmuch while still maintaining her old Neomutt setup. And Neomutt's notmuch backend already respects notmuch config.

Many people use notmuch cli for sorting and automaticall tagging emails. So making sure queries between Aerc and cli work identically can help their workflow a lot (alternative: is there a way to make notmuch cli ignore the config and make it work like Aerc?). It will reduce their debugging effort, and allow to carefully craft a query in Aerc and then copy-paste it into their notmuch tag invocation.

What are the arguments against supporting notmuch config?

If we're not loading notmuch config (or while we are discussing this) would it make sense to document the current behavior somewhere? I feel that there's more people like me who will expect all programs that use notmuch to behave exactly like notmuch cli does. I've never seen either aerc or notmuch configs say that.

1. Do tag: +foo on one of your messages in Aerc.

2. Put

   [query]
   foo = tag:foo
   

   in your notmuch config file.

3. Run (expected results are shown)

   $ notmuch count tag:foo
   1
   $ notmuch count query:foo
   1
   

4. Do :cf tag:foo in Aerc. This will show the tagged message from step 1 (as expected).

5. Do :cf query:foo in Aerc. This doesn't display the message, but I exptected it to, since the same Notmuch query does match the message.

Clearly, the behaviour of notmuch command and seach in Aerc with :cf differ. Is this a bug?

Thanks! You guys rock!

To reproduce:

1. Send a signed and encrypted email to yourself. The email should contain some body text and an attachment (I used a text file kek.txt as the attachment).
2. Open the email, you should see the message body (of text/plain content type).
3. Now do :open to open it in an external program.
4. Aerc tries to open a file named aerc-1111127589.gpg, even though the file itself is a .txt (the file contents are correct though).

This causes the text/plain email body to be open using a program for gpg files (Seahorse, in my case), and I'd expect it to be open with my viewer for text files.

When the email is not signed and encrypted at the same time, the name of the open file doesn't have the .gpg extension. Is there a way to get the same behavior with signed and encrypted emails too? A file with no extension at all should do fine, I think.

Thanks a lot for fixing this. I can't reproduce the bug anymore.

https://paste.sr.ht/~ph14nix/654fb1ca68771840713be8445cc48f74bcc34326

1. Open this PGP-signed email in Aerc.
2. Navigate using Ctrl+j to the attachment.txt.
3. Pipe it using |less.
4. Aerc opens new tab displaying

-----BEGIN PGP SIGNATURE-----
…
-----END PGP SIGNATURE-----

instead of the selected attachment. The same happens if you save the attachment instead of piping it. Normally, it should use the attachment contents.

I speculate something must be off with the index of the attachment that is being piped.