Methods for modifying multiple tasks

[jmriego]

Hi! First of all, thank you for your hard work. I found out very recently about vit and I find it amazing. I can't believe it's not a lot more popular between the Taskwarrior tools!

I was trying to make changes in multiple tasks at the same time and was wondering if there's some way of doing this.

The two ways I would think of are similar as what you would do in vim:

1. Mark multiple tasks with something like mt and then you run a command that would affect all of them. This should also work for when you have mappings that use the task UUID and would run them multiple times with a different UUID each
2. Add a . mapping that will repeat the previous action. In my opinion itt would also have to work for things like :!rw task .... so it would be a bit different of the same mapping in vim that don't include :commands.

Does this sounds like something that could be added? Thanks!

[jmriego]

I suppose another option would be a v or V mapping to start a selection but that would require the tasks you want to modify to be next to each other

[thehunmonkgroup]

Multi-task operations have been on my wish list for awhile.

It's not something I have time to implement now, but I'd be happy to look at a PR for it.

I do suspect the implementation will be a lot trickier than you may imagine. Adjusting the interface to display multiple selections and operate on multiple tasks will likely involve some fairly major refactors, and a poor implementation would likely be pretty buggy.

[jmriego]

I can imagine! That's why I mentioned several methods that could potentially work. As you said, there's the interface part with also changes in the highlighting. You have to think about multiple types of changes and running task commands that you don't know what could affect...
So I think the easiest method would probably be the dot, but what do you think? I might have time to have a look at the code if that makes sense

[thehunmonkgroup]

The dot would probably be a good start. I still think that might have some dragons in it, but conceptually, "store last action, repeat when told" seems fairly straightforward.

Also, I think even if we start here, adding the multiple highlighting later wouldn't conflict, it would just be another usable method.

[thehunmonkgroup]

#267 is taking a first stab at this, still a long ways to go...

[kevinstadler]

Since bulk-editing is also a feature I'd really like to be able to use from within vit I've had a little look at the code. Here's some ideas, would love to hear some feedback before I go forward and actually implement anything:

• task's interface for bulk editing is simply task <filter> <command> ..., so in terms of the complexity of operations like modify, delete, start, stop etc. it doesn't matter whether the <filter> is a single uuid (that's the only use case invoked by vit operations at the moment), a space-separated list of uuids, or a logical filter expression. I'd therefore suggest working towards refactoring the existing editing operations to also process lists of tasks or filter expressions and pass them on to the already existing single self.execute_command(['task', ...]) command. This would mainly be around here in the code, where the commands would have to look at other arguments passed in data to see whether the command target is really just one uuid, or something else (although some code like for done might also be in the TaskListModel?):
  

  vit/vit/application.py

  Lines 358 to 370 in 62273a2

  	elif op == 'modify':
  	# TODO: Will this break if user clicks another list item
  	# before hitting enter?
  	if self.execute_command(['task', metadata['uuid'], 'modify'] + args, wait=self.wait):
  	self.activate_message_bar('Task %s modified' % self.model.task_id(metadata['uuid']))
  	elif op == 'annotate':
  	task = self.model.task_annotate(metadata['uuid'], data['text'])
  	if task:
  	self.table.flash_focus()
  	self.update_report()
  	self.activate_message_bar('Annotated task %s' % self.model.task_id(task['uuid']))
  	elif op == 'tag':
  	task = self.model.task_tags(metadata['uuid'], args)

• Since bulk-editing is a pretty advanced feature I think it's also more useful to first focus on scriptability, UI implementations can always be added later. In particular I'm thinking about a "bulk-edit all tasks in current view" use case, which really only requires information about (1) what the default filter of the current report+context is and (2) what other custom filters were applied on top of that within vit. I know I can already implement the former using a custom variable replacement that invokes task to find out the relevant filters, but the latter needs access to vit's runtime application variables. I'd therefore propose to add support for (something like) the following variable replacements to vit:

  1. {REPORT_FILTER} (possibly also {CONTEXT_FILTER}?)
  2. {EXTRA_FILTER} (replaced by the application's self.extra_filters)
  3. {VIEW_FILTER} (this one's simply ({REPORT_FILTER}) and ({EXTRA_FILTER}))

With these two things in mind I think there could be a nice 3-step roadmap, each of which provides new functionality that builds/relies on the previous ones:

1. expose current filter as well as the underlying filters of the current report via variables that users can use in their macros to make external calls like :!rw task {VIEW_FILTER} modify ...
2. for each task operation that supports bulk editing, add a TASK_*_BULK action to the already existing ones, making sure that vit's underlying task invocation functions support filter expressions and task-list targets
   

   vit/vit/application.py

   Lines 737 to 784 in 62273a2

   	def task_action_modify(self):
   	uuid, _ = self.get_focused_task()
   	if uuid:
   	self.activate_command_bar('modify', 'Modify: ', {'uuid': uuid})
   	self.task_list.focus_by_task_uuid(uuid, self.previous_focus_position)
   	def task_action_start_stop(self):
   	uuid, task = self.get_focused_task()
   	if task:
   	if self.confirm:
   	self.activate_command_bar('start-stop', '%s task %s? (y/n): ' % (task.active and 'Stop' or 'Start', self.model.task_id(uuid)), {'uuid': uuid, 'choices': {'y': True}})
   	else:
   	self.task_start_stop(uuid)
   	self.task_list.focus_by_task_uuid(uuid, self.previous_focus_position)
   	def task_action_done(self):
   	uuid, task = self.get_focused_task()
   	if task:
   	if self.confirm:
   	self.activate_command_bar('done', 'Mark task %s done? (y/n): ' % self.model.task_id(uuid), {'uuid': uuid, 'choices': {'y': True}})
   	else:
   	self.task_done(uuid)
   	self.task_list.focus_by_task_uuid(uuid, self.previous_focus_position)
   	def task_action_priority(self):
   	uuid, _ = self.get_focused_task()
   	if uuid:
   	choices = {}
   	for choice in self.task_config.priority_values:
   	key = choice.lower() or 'n'
   	choices[key] = choice
   	self.activate_command_bar('priority', 'Priority (%s): ' % '/'.join(choices), {'uuid': uuid, 'choices': choices})
   	def task_action_project(self):
   	uuid, _ = self.get_focused_task()
   	if uuid:
   	self.activate_command_bar('project', 'Project: ', {'uuid': uuid})
   	def task_action_tags(self):
   	uuid, _ = self.get_focused_task()
   	if uuid:
   	self.activate_command_bar('tag', 'Tag: ', {'uuid': uuid})
   	def task_action_wait(self):
   	uuid, _ = self.get_focused_task()
   	if uuid:
   	self.activate_command_bar('wait', 'Wait: ', {'uuid': uuid})

3. add support for manual task selection (like in the pull request above), with the selection list populated by the UI seamlessly passed through to the newly added _BULK commands

I'd be keen to get some work done on this (especially step 1) soon, so let me know what you think!

[thehunmonkgroup]

@kevinstadler on first read, this sounds like a solid plan. I'm a little concerned about ripping out the tasklib stuff and replacing it with direct calls to the task binary -- it's been so long since I coded that, I can't remember what the specific advantages were when using tasklib. I'm sure there were some ;)

At the same time, it's always felt clunky to me to have that hybrid model of tasklib/task binary. If we went the route you're proposing, perhaps we should expunge tasklib (at least for all the write operations).

If you want to take a crack at the PR, I'll commit the time to review and offer suggestions/improvements. I agree that having this feature would be a big plus, and I don't have the time to code it. As long as the code is clean and maintainable, we can get it in.

[scottkosty]

Thanks for working on this!

I did not read the details, but would it make sense to add the under-the-hood work to tasklib? Is the library still maintained? It seems these features might be useful to other Taskwarrior tools that rely on tasklib. I don't know anything about it though so perhaps it is inherently out of the scope of tasklib.

Regarding the interface, two tools that I've used as inspiration for working on vit are mutt and ranger. Multiline (non-consecutive) selections are more natural in those two tools than in Vim so their interfaces might provide some good inspiration.

Again, thanks for your time on this! It is a feature that has been requested by a lot of users over the years and no one has dared to jump down the rabbit hole :)

[thehunmonkgroup]

I did not read the details, but would it make sense to add the under-the-hood work to tasklib?

The problem with that is that the task binary is so darn flexible. I think it's going to be a challenge to account for all that we want to support only using tasklib. The project is still maintained, so it might be worth filing a ticket to see what the dev says.

[scottkosty]

The problem with that is that the task binary is so darn flexible. I think it's going to be a challenge to account for all that we want to support only using tasklib. The project is still maintained, so it might be worth filing a ticket to see what the dev says.

Ah that is good to know. Thanks. Sounds like it might be one of those "sure that's the nice thing to do in theory but in practice it makes things a lot more complicated" things.

[tbabej]

Hey guys,

just randomly chiming in here, but I'm wondering if you want to jump on a call to discuss this? I wrote like ~70% of tasklib and if my memory serves me right, it covers a pretty broad range of use cases. I am using it quite successfully in taskwiki.

[kevinstadler]

I didn't even realise that tasklib was being used, as the modify command that I looked at already executes task directly via the application's self.execute_command() (same as at least 6 other commands, in particular undo, sync, edit, info, add and context). I wonder if the choice not to go through tasklib for these was the fact that many of them are quite complex so that their failure might require interactive prompting, which is then automatically handled by task?

Unless you want to make a push towards passing modify through tasklib as well, the current code:

vit/vit/application.py

Line 361 in 62273a2

if self.execute_command(['task', metadata['uuid'], 'modify'] + args, wait=self.wait):

can already support bulk-editing via any of the following minimal changes:

• passing a filter string in place of metadata['uuid']
• passing a space-separated string of uuids as metadata['uuid'] instead of just a single uuid
• passing more uuid arguments between 'task' and 'modify' (I think all arguments just get joined with spaces for execution anyway)

[thehunmonkgroup]

@tbabej @kevinstadler I'm game to jump on a call to discuss the best implementation.

Again, it's been so long since I built those pieces, I cannot recall the precise reasoning. I do remember that I tried to use tasklib as much as possible, and where I couldn't figure out how to use it, I fell back to the task binary directly.

I'm a little concerned about scope creep if we elect to run everything through tasklib. I guess it depends how hard that is, I haven't studied that code enough to have an opinion.