Pre/post triggers for VIT actions

[thehunmonkgroup]

I've been thinking about how VIT behaves after creating a new task -- currently it simply reloads the report fresh.

There's some convenience things we could do, but I'm unclear about how useful they might be, and /or how best to implement them. Ideas:

• Focus on the added task after the report reloads. This could be just hard wired, or a config value with a sensible default (which is?)
• Run a custom action/command after the task is added. Examples could be {ACTION_TASK_EDIT} or !rw myscript.sh {TASK_UUID}. Obviously a config option disabled by default.

Looking for some thoughts on the above and any other suggestions folks might have.

[scottkosty]

• Focus on the added task after the report reloads. This could be just hard wired, or a config value with a sensible default (which is?)

I think this was also requested at #109.

• Run a custom action/command after the task is added.

Interesting. This opens up a huge box of possibilities. Perhaps you want to avoid this rabbit hole, but I cannot help but think about it so I log some thoughts here: What are all the possible triggers/signals that hooks could condition on? Adding/modifying/completing/deleting a task are some examples; detecting that pending.data changed (#191) is another. Perhaps this relates to the plugin architecture that you have in mind.

[thehunmonkgroup]

Cool, excellent idea, and glad I asked!

I've updated the title of the issue accordingly.

It should be fairly easy to implement these custom post triggerrs (and for that matter, pre triggers), and to add config options for each of them. At the plugin level, if/when that is implemented, we could emit events for each of the triggers that any plugin can listen for.

So now, we need to make some decisions:

• What VIT actions do we want a pre/post trigger for?
• What's the format of the config options for pre/post triggers?

[scottkosty]

Ah good point about pre-triggers! Probably we should study interfaces of other frameworks. I've never actually used Taskwarrior hooks or Git hooks.

I would add another question that might affect decisions: what are some motivating examples for practical things that this feature can be used for? It might be nice to go through the list of issues and see if any of them could be addressed with this sort of framework. I can take a look at that, but probably not for a couple of weeks.

[scottkosty]

I can take a look at that, but probably not for a couple of weeks.

I wasn't able to get to this and am not sure when I will now. @thehunmonkgroup if you are waiting on me to do this, let me know and I will try to get to it when I can.

[thehunmonkgroup]

@scottkosty I'm not rushing this issue at all, so when you have time go ahead and post your findings here.

[scottkosty]

@thehunmonkgroup sounds good, thanks.

[ahillio]

This would be a lovely feature enhancement, most particularly in my case to be able to automatically highlight/select a task after it's created.

Is this proposed pre/post hook triggers dependent on a plugin architecture first being implemented?

[thehunmonkgroup]

@ahillio I don't think it is, as long as it's architected to easily support the addition of the plugin architecture in the future it could be done first.

[nfraprado]

I just noticed that when a task is added, the cursor goes back to the first task in the report, probably due to the report being reloaded.

• Focus on the added task after the report reloads. This could be just hard wired, or a config value with a sensible default (which is?)

To me it would make most sense to always focus on the previously focused task, so that could be the default.

Maybe then setting the config value to focus on the added task would focus on the previously focused task as a fallback if it isn't in view?