~rjarry/aerc#249: 
new message bell not working

The terminal bell isn't rung when my IMAP account receives a new message. Tested with as-of-now-latest master (7b4c8f67eb5f).

What seems a little strange to me is that the Beep() call is in the triggerDirectoryChange callback of MessageStore rather then triggerNewEmail. However moving it there only produces

aerc.go:153: should beep, but no beeper

warning in the log. This is as far as I can guess because the UI context of the trigger is not DrawableInteractiveBeeper.

It's been suggested that the issue could be caused by the IMAP server not supporting the \Recent flag, however this should not be the case as evidenced by the above warning and also by the fact that the mail-received hook, which I have been lead to believe uses this mechanism too, works for this account (albeit it is only fired once the tab of the receiving account is opened).

I have {{.Recent}} in the tab title and that changes correctly even before the tab is opened. But so it does for another IMAP account where the hook does not work at all and I have been told (on IRC) that this variable is in fact possibly not related to the \Recent flag.

Also, the bell is rung soon after aerc starts up when placed in the triggerDirectoryChange callback which I guess happens as all my mailboxes are being opened.

Status
RESOLVED FIXED
Submitter
~balejk
Assigned to
No-one
Submitted
a month ago
Updated
a month ago
Labels
No labels applied.

~rockorager a month ago

I've always been curious about the directoryChange callback as well, it's a very convoluted area of the codebase.

Looks like the issue is that aerc.beep is only set by aerc.OnBeep, We call this by type casting aerc to a DrawableInteractiveBeeper, and there is a huge nesting of interfaces here that I haven't looked through to see if aerc still satisfies the interface.

~balejk a month ago

Thank you for looking into this!

Sorry for the confusion: it seems that you are right, aerc probably no longer satisfies the interface - I assume this is related to the Vaxis switchover then?

To be more precise: I tested this again with 0.17.0 and there I get the bell on startup and I see no beeper warnings in the log. New messages still don't beep though.

With latest master, I don't get the startup bell and I see several beeper warnings in the log -- I assume these are the startup ones.

And I have now verified that moving the beeping into the NewEmail trigger on top of 0.17.0 causes new messages to beep, but again only after the receiving account's tab is opened -- this is a general problem of the trigger it seems.

~rockorager a month ago

Must be related to the Vaxis switch, I must have dropped a method on aerc, my bad!

Do you want to send in your patch?

~balejk a month ago

There is no patch, I am just guessing based on what I write above but haven't looked whether in fact and what has been dropped. I can look into it later but feel free to beat me to it :-)

~balejk a month ago

The fix for the Vaxis breakage is up :-)

It seems that what broke the message bell in the first place is 24eab0f5ef63 which was meant to make the mail-received hook fire even when the tab is not focused.

I have compiled the revision prior to this commit and there the bell works even if the tab hasn't been opened previously (since the start of aerc). Whereas, as previously noted, on current master I only get the mail-received hook after I focus the corresponding account tab (and for instance for o365 not even then). So in other words the aforementioned commit doesn't fix the issue it was meant to solve for me.

I haven't yet looked into how exactly that commit broke the bell but I wonder if instead of moving the bell into the triggerNewEmail callback we could move the mail-received hook into the triggerDirectoryChange callback (after it's fixed) as that seems to be executed not only when the tab is not currently focused (even for me :-) ), but also even if the tab hasn't been focused yet since the start of aerc, which is listed as one of the limitations of the fix commit. (And when I say move into the other callback, I mean rather try to understand how the two triggers differ and see if they could be made into one which would keep the benefits of both and none of the problems of either :-) )

~rjarry REPORTED FIXED a month ago

Karel Balej referenced this ticket in commit dc306cf.

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