Idea: Activities as Templates

[lmkerbey-mdb]

I have classes of activity that I do every day where the desirable buffer configuration is predictable for all instances of the activity. Each activity corresponds roughly to one JIRA. For workflow/procedural reasons, it is often most efficient for me to have several such activities in flight simultaneously and to be able to switch between them as feedback comes in/builds/deployments finish, etc. What is unpredictable day-to-day is how many such activities I will end up juggling at any one time.

Given the current design of activities.el, one potential solution would be to simply define multiple identical activities, just giving them ordered names (e.g. taskA, taskB, taskC or task1, task2, task3) and then calling them up in order as I have a need. However, apart from being inefficient at the point of definition, in the interests of being generically usable, I can't give these activities descriptive names. If I have to exit Emacs and later I need to resume work on these tasks, I have to try to remember which is which. If I have to shelve certain tasks and shift to a different set of tasks entirely (not at all uncommon), then I either have to make additional task definitions to make up the difference, or else revert existing ones to their default state and lose the convenience of being able to pick up where I left off when I do have the opportunity to return to the previous tasks.

My proposal is to enable using an activity as a kind of 'template' (or, if you prefer, 'parent') which can be used to spawn instances that have their own names. This provides for an arbitrary number of tasks of identical procedural form, suitable for this simultaneous work scenario. Rather than having it be a different type of activity definition, perhaps this could be implemented through a new function, say, activity-spawn that clones the activity definition and prompts you for a new name for this clone, then creates the appropriate frame/tab for the clone. The clone functions like a fully-fledged activity for its lifecycle, supporting reversion, suspension, resumption, etc. When you're done with it, you discard it without any effect on the template/parent.

[alphapapa]

This seems like a good idea to me. I sometimes do something similar with C-x t n, but that just duplicates the tab, not the activity associated with it.

IIUC, what you describe could currently be accomplished with roughly this sequence:

1. activities-resume for the "parent"/"template" activity.
2. Work in the activity, making it more specific to the subtask according to procedure.
3. activities-define to define a new activity for the subtask, with a new name.
4. activities-resume for the "parent"/"template" activity, again (maybe with C-u argument to reset it to default state).
5. Goto 2.

But with an activities-clone command, it could work something like:

1. activities-clone the "parent"/"template" activity, being prompted for a name (by default, prefixed with the name of the activity being cloned), and optionally resetting the clone to the default state (some users might want to always reset the clone to default, while others might not).
2. Work in the activity.
3. When ready to work on a similar task from the same starting point, goto 1.

Is that close to what you're imagining?

[lmkerbey-mdb]

Yes, that's exactly what I have in mind. Thanks for taking this under advisement.

[alphapapa]

Cool, thanks. I probably won't work on this soon myself, but it should be simple to implement, and I'll be glad to review and merge patches.