~sircmpwn/aerc2#290: 
New email trigger not working

The new email trigger (new-email=exec ) doesn't execute commands. (:exec directly in aerc does work)

Status
REPORTED
Submitter
Edwin Vigneau
Assigned to
No-one
Submitted
1 year, 1 month ago
Updated
a month ago
Labels
bug imap

~jeffas 1 year, 1 month ago

What backend are you using by chance?

Edwin Vigneau 1 year, 1 month ago · edit

What do you mean by backend? I'm using arch linux and bash.

~sircmpwn 1 year, 1 month ago

Mail backend. IMAP, notmuch, and maildir are your options.

Edwin Vigneau 1 year, 1 month ago · edit

IMAP (Gmail)

~sghctoma 10 months ago

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".

~yaymukund 2 months ago

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 of LAST_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.

~yaymukund 2 months ago

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.

~miterion a month ago

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.

~labrat a month ago

~miterion a month ago

~labrat Thank you for the patch. So far, it is working great! Will message when I stumble upon a bug.

Register here or Log in to comment, or comment via email.