The new email trigger (new-email=exec ) doesn't execute commands. (:exec directly in aerc does work)
What backend are you using by chance?
What do you mean by backend? I'm using arch linux and bash.
Mail backend. IMAP, notmuch, and maildir are your options.
IMAP (Gmail)
I've also run into this problem, and did some digging. There are two conditions for executing the new mail trigger (lib/msgstore.go@193):
- the \Seen flag must no be set
- the \Recent flag must be set
From what I've seen, GMail does not set the \Recent flag on any messages. I've logged out of all my clients (so that they don't unset the flag), sent myself a mail, and sent SELECT commands via socat; the RECENT count was always zero. I don't know if this is a bug in Gmail, or their IMAP implementation still does not support the \Recent flag, but this explains the lack of trigger execution.
I also have a question regarding new mail triggers: Was that a design decision that new mail triggers are only executed on messages arriving to the currently selected folder, or does it work this way because of some technical difficulty, performance reasons, etc.? I think this might be confusing and can be perceived as "not working".
Just want to confirm I'm experiencing this as well. If I naively remove the
recent
condition, it displays a notification for every single unread message as it's displayed. Maybe you want to keep some kind ofLAST_SEEN_TIMESTAMP
and you check the time of receipt? If that seems like an amenable approach, I'm happy to take a stab at it.Thank you for building and maintaining aerc! Really fantastic piece of software.
I was able to almost fix it locally by applying the following patch:
diff --git lib/msgstore.go lib/msgstore.go index b95b68f..06c750e 100644 --- lib/msgstore.go +++ lib/msgstore.go @@ -19,6 +19,9 @@ type MessageStore struct { // Ordered list of known UIDs uids []uint32 + // Only newer uids will the invoke new email trigger + lastSeenUid uint32 + selected int bodyCallbacks map[uint32][]func(*types.FullMessage) headerCallbacks map[uint32][]func(*types.MessageInfo) @@ -196,16 +199,14 @@ func (store *MessageStore) Update(msg types.WorkerMessage) { store.Messages[msg.Info.Uid] = msg.Info } seen := false - recent := false for _, flag := range msg.Info.Flags { - if flag == models.RecentFlag { - recent = true - } else if flag == models.SeenFlag { + if flag == models.SeenFlag { seen = true } } - if !seen && recent { + if !seen && msg.Info.Uid > store.lastSeenUid { store.triggerNewEmail(msg.Info) + store.lastSeenUid = msg.Info.Uid } if _, ok := store.pendingHeaders[msg.Info.Uid]; msg.Info.Envelope != nil && ok { delete(store.pendingHeaders, msg.Info.Uid)I think you'd also want to compare against
UidValidity
and persist both values to disk for use across reboots.
I have the same problem with the maildir backend ~yaymukund's patch also fixed the notification problem for me. Would be nice to see this on master, even without the disk persistence.
~miterion apply https://lists.sr.ht/~sircmpwn/aerc/patches/13901 and give feedback
~labrat Thank you for the patch. So far, it is working great! Will message when I stumble upon a bug.
~labrat: There seems to be no bigger problem in my experience with your patch. Any plans to merge it soon?
With https://lists.sr.ht/~sircmpwn/aerc/patches/13901 applied, this seems to work for me.
I can also confirm that this patch fixes the issue. Any chances of merging it into master?
I have applied https://lists.sr.ht/~sircmpwn/aerc/patches/13901 on https://git.sr.ht/~rjarry/aerc.
I will have a closer look at ~yaymukund's patch for the Gmail IMAP issue. I'm not sure fixing it in message store is the right way to go.