Had finally time to investigate this issue and found out the reason.

The problem is related to maildir++ where Inbox emails are located in

./cur
./new
./tmp

, whereas emails in other folders are located in e.g.

./.Archive/cur
...

Problem 1:

When using mv -a ACCOUNT Inbox, aerc incorrectly creates a new .Inbox directory (with three empty subdirs: cur, new, tmp).

When you then launch aerc it somehow toggles between ./cur and ./.Inbox/cur.

Problem 2 -- caused by problem 1:

When using mv Inbox e.g. from within the Archive folder, the relevant message is moved to ./.Inbox/cur instead of ./cur, because aerc probably assumes the default maildir format. This may be the correct behavior in case aerc does not check for maildir++ in any other way.

When the obsolete ./.Inbox folder is deleted, mv Inbox correctly moves emails to ./cur.

Please let me add one more detail: With regard to this issue both accounts are totally unrelated.

When there are emails in both inboxes and aerc is launched, messages are displayed either in none, both or only one of the accounts.

So, to reliably display emails in the work account's inbox I have to launch aerc with aerc -a work about 3 to 6 times.

This is kind of related.

On Sat Jun 29, 2024 at 11:52, ~neff outgoing@sr.ht wrote:

Oh, my email provider seems to have issues with ~ in email addresses or something. I'll investigate. I sent the email twice. (For sourcehut I use the tuta webmail backend, not aerc. Good reason to change this.)

Sourcehut provides an alternative address for this case:

u.rjarry.aerc-devel@lists.sr.ht

~inwit reviewed the patch. Is this sufficient?

Sorry for the inconvenience and thanks again.

Yes, it is, thanks! :)

-- +36305425054 bence.ferdinandy.com

Oh, my email provider seems to have issues with ~ in email addresses or something. I'll investigate. I sent the email twice. (For sourcehut I use the tuta webmail backend, not aerc. Good reason to change this.)

~inwit reviewed the patch. Is this sufficient?

Sorry for the inconvenience and thanks again.

On Sat Jun 29, 2024 at 10:54, ~neff outgoing@sr.ht wrote:

OK! I have never used an email based git workflow.

So, I just sent an email to

~rjarry/aerc-devel@lists.sr.ht
Re: [PATCH aerc] rfc822: properly parse address lists

and hope this is the correct way to review your patch.

Yes, that workflow is that you reply to the email that was the patch with say

Tested-by: Name name email@example.com

which will then end up in the commit being applied.

On the other hand, I am not seeing your reply yet ...

-- +36305425054 bence.ferdinandy.com

OK! I have never used an email based git workflow.

So, I just sent an email to

~rjarry/aerc-devel@lists.sr.ht
Re: [PATCH aerc] rfc822: properly parse address lists

and hope this is the correct way to review your patch.

Fantastic. Your patch works perfectly. Thanks a lot -- also for all your work on aerc.

Hi aerc team,

This is my setup: maildir++ with two accounts: "private" and "work".

After moving an email from private to work with :mv -a work Inbox, the Inbox is (frequently, but not always) display as empty when launching aerc, although the new and other emails are located in this folder.

I think this must has to do with the new -a flag, because I never noticed anything like it before.

Some more observations:

Switching folders or account tabs never solves this problem. Aerc has to be relaunched (multiple times).

When I move all emails from Inbox to another folder, they are reliably displayed there. When I move them back to Inbox, the described problem persists.

So, I bravely moved some emails from work to private using :mv -a private Inbox. Now the Inbox folder for private account is also affected.

Before move -a was possible I sometimes moved emails using the command line. This never caused a problem.

This is a rather severe problem for me, because I try to keep my Inbox folders empty and I'm usually not surprised about an empty folder.

Thank you!

Thank you. This would be a good solution, if such a fallback is not to be included into the msgviewer, because it's easily extendable.