Automatic thread_index.refresh after poll

[dnebauer]

In my notmuch pre-new hook I am deleting mail files with the tag 'delete' as per these notmuch instructions. After astroid polls I have to manually refresh the thread index, i.e., press $ to trigger thread_index.refresh, to remove deleted mail.

I have played with capturing the notmuch database revision before deletion and running astroid --refresh <revision> as the last step in poll.sh. The problem, of course, is that running this command in poll.sh starts another instance of astroid. If I manually run this command after a poll, it appears to execute successfully and returns success, but the thread index in the running astroid instance does not refresh.

Is there anyway to automate a refresh of the thread index following each poll, i.e., simulate pressing the $ key?

[gauteh]

You do not need to do astroid --refresh .. if the poll script is launched from astroid, astroid will update any messages changed since the start of the poll automatically. Unfortunately, there is no way to notice if a message has been deleted - since it will no longer show up in the query as changed if it no longer exists. It would be possible to have an option for always doing a full refresh after a poll, but this would cause all thread-indexes to be re-loaded and would usually be quite slow (if you have many large queries open) - we used to do this before there were revisions in the notmuch database.

[dnebauer]

Well, I have no idea if my use case will ever be common, but I'd sure like that option to always do a full refresh after a poll. Please consider this one vote in favour of adding it...

Thanks for your prompt help with all my recent issues and for a great email tool.

[gauteh]

Can you try #453?

[dnebauer]

When I used the config option it did exactly what I hoped for. I did a bit of limited stress-testing, such as opening the shortly to be deleted thread in thread view during polling and remaining in the thread during refresh, and astroid continued to run and behave sensibly and predictably.

I'm not sure how the --refresh option is used to affect refresh behaviour. I tried issuing astroid --refresh 0 from a terminal while an instance of astroid was already running. It did not change the behaviour to refresh-after-poll. I tried running astroid in the first place with the command astroid --refresh 0; it ran with the default behaviour of no-autorefresh-after-poll.

I'm happy with controlling this behaviour using the config option and would love to see this feature merged into the main branch.

I don't mind doing further testing if it contributes to merging this feature into main.

[gauteh]

dnebauer writes on januar 9, 2018 11:29:

When I used the config option it did exactly what I hoped for. I did a bit of limited stress-testing, such as opening the shortly to be deleted thread in thread view during polling and remaining in the thread during refresh, and astroid continued to run and behave sensibly and predictably.

I don't think the thread-view would be affected? Only the thread-indexes.

I'm not sure how the `--refresh` option is used to affect refresh behaviour. I tried issuing `astroid --refresh 0` from a terminal while an instance of astroid was already running. It did not change the behaviour to refresh-after-poll. I tried running astroid in the first place with the command `astroid --refresh 0`; it ran with the default behaviour of no-autorefresh-after-poll.

It does not change the behaviour, it causes a one-off refresh of all open thread-indexes.

I'm happy with controlling this behaviour using the config option and would love to see this feature merged into the main branch. I don't mind doing further testing if it contributes to merging this feature into main.

Good, if it works as expected I'll merge.

[gauteh]

Gaute Hope writes on januar 9, 2018 11:31:

> I'm not sure how the `--refresh` option is used to affect refresh behaviour. I tried issuing `astroid --refresh 0` from a terminal while an instance of astroid was already running. It did not change the behaviour to refresh-after-poll. I tried running astroid in the first place with the command `astroid --refresh 0`; it ran with the default behaviour of no-autorefresh-after-poll. It does not change the behaviour, it causes a one-off refresh of all open thread-indexes.

Note that if you want to manually trigger a refresh, but still use a poll script launched recurrently by astroid, it is a good idea to exit with status != 0 from the poll script so that astroid does not refresh (redundantly) as well.

[dnebauer]

Now I get the use of --refresh 0. So, for me the changes from #453 work the way you described: when I use the poll.always_full_refresh = true config option it refreshes the thread index after polling (and withstood some limited stress testing), and astroid --refresh 0 causes a running instance of astroid to immediately refresh the thread index.

Hope to see this merged soon!

[gauteh]

dnebauer writes on januar 9, 2018 12:05:

Hope to see this merged soon!

Merged!