aboutsummaryrefslogtreecommitdiffstats
path: root/commands/testdata/foo/bar.json
diff options
context:
space:
mode:
authorKarel Balej <balejk@matfyz.cz>2024-05-07 13:24:00 +0200
committerRobin Jarry <robin@jarry.cc>2024-05-09 22:11:14 +0200
commitdc306cf6dcd3d99c9f8ee4db486864b050dc7af7 (patch)
tree310aa908b3c876b02970fc62393b32c37dce31bc /commands/testdata/foo/bar.json
parent4c0211c4f9a7fad18f8ce97535e785fb5013b1f0 (diff)
downloadaerc-dc306cf6dcd3d99c9f8ee4db486864b050dc7af7.tar.gz
msgstore: restore the directoryChange bool to fix new message bell
In 24eab0f5ef63 the condition under which the triggerDirectoryChange callback is executed was changed so that it would now only run if there were new messages in the currently scrolled into view part of the message list whereas previously it ran for new messages anywhere in the list. The motivation for this was to make the mail-received hook work even when the tab of the receiving account is not currently focused by fetching the new message's/s' headers needed for the hook to execute based on what changed in the scrolled into part of the list. This limitation is needed because apparently we don't currently have a better way to recognize new messages other than comparing the list of UIDs provided by the worker and that kept by the store. My current understanding is that we cannot remove the scroll view limit because then we would be fetching headers for all messages in the directory which can be a somewhat intensive operation. However we can disregard the view limit for the bell as that does not require the headers: it only cares about that something has changed. It is noteworthy that the bell is rung on aerc startup: I assume that this occurs with the initial load of the message store for every account when the else branch where directoryChange is set to true inevitably executes. Overall, this patch is more of a workaround than a proper fix: the ideal situation would be if we were able to fetch headers for new messages independently of the scroll status. However as this is how this was before, it should be suitable as a temporary solution. There are also further problems here: currently we have triggerNewEmail and triggerDirectoryChange callbacks which are both supposed to run when new mail is received, the latter only implicitly. And yet they both use a different mechanism and thus execute under different circumstances. It would be ideal to move the bell into the new mail trigger and get rid of the directory change one as it is otherwise unused. However this is not done here because for some setups the new mail trigger does not run until the tab is focused which is what the aforementioned commit was meant to fix but apparently succeeded in doing so only partially. The directoryChange trigger does not have this drawback and thus should be kept until the issue is resolved for all setups. Also note that for instance for O365 mail the bell still doesn't work properly as there new mail only appears in the store after the given folder is reopened (:prev-folder :next-folder) and the bell is thus rung only then. Fixes: 24eab0f5ef63 ("msglist: fetch headers even when not focused") Fixes: https://todo.sr.ht/~rjarry/aerc/249 Changelog-fixed: Restore previous behaviour of the new message bell which was broken in the last two releases for at least some setups. Signed-off-by: Karel Balej <balejk@matfyz.cz> Acked-by: Robin Jarry <robin@jarry.cc>
Diffstat (limited to 'commands/testdata/foo/bar.json')
0 files changed, 0 insertions, 0 deletions