I think kanshi is already supposed to do what you're asking. If I understand correctly, it listens to all monitor change events from the WM and applis configuration after each event. It never misses an event.

So if some monitors appear with a delay, it will apply incomplete config first, then find the lagging screen and apply full config. If it's not working for you, this could be either incorrect configuration or a bug.

Ivan

On Thu Dec 5, 2024 at 10:50 AM CET, ~spacefrogg wrote:

I still have this problem with in a situation where I connect two monitors with slow startup times via a USB-C docking station. Kanshi could need some programmable grace period here, where it detects the change but waits to react on them. In my case the monitors appear shortly, vanish again and appear again. Kanshi applies its configuration in the middle of this tumoil ending in any of: one random monitor missing to light up or both monitors lighting up correctly and/or XWayland crashing (due to missing outputs during the "vanish period"). So, I envision the following "grace protocol":

• detect the change (but don't try to match with a profile) and start the grace counter
• monitors show up/vanish as they do...
• after grace period, register the final configuration again and apply profile matching

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.