[EX-55] task <filter> move <file>

[taskwarrior]

David Patrick on 2010-09-27T22:05:06Z says:

One of taskwarriors strengths is that one can keep separate .data files, and switch between them with

% task rc:< path-to-alternate-file >

but if one wants to move some tasks from one file to another, that's a different story. Although .data files are just text files, and some adept editing could do the job, wouldn't it be swell to have a command to do just that ? like

% task move proj:feng-shui ~/.task/personal-enlightenment.pending.data

huh? wouldn't it ?

[taskwarrior]

Migrated metadata:

Created: 2010-09-27T22:05:06Z
Modified: 2017-01-17T02:54:01Z

[taskwarrior]

David Patrick on 2011-09-25T23:20:14Z says:

The potential need to move a task from one file to another increases when we get task-server working, and we start sharing different files different ways. With the new syntax, the above example would be wrong, and as I thought about how it should be corrected, and as the discussion re; moving annotations from one task to another unfolds, I see that the task move command could be extended, and act differently depending on the scope, to either move whole tasks (or filtered groups of tasks) from one pending.data file to another, but it could also be used to move one attribute (or a set of attributes) from one task to another. for example;

% task proj:feng-shui move ~/.task/personal-enlightenment.pending.data

to relocate all Feng-Shui project tasks to another data file, or

% task 143 annotation.any: move 722

to relocate all annotations from task 143 to task 722

The move command offers a whole lot of power, and will have to be used with caution, but it could come in very handy.

[taskwarrior]

Eric Fluger on 2011-09-26T03:07:13Z says:

• • as task moves records from pending.data to completed.data the underpinnings for this may already exist.
  • • i suspect the desirability of being able work with more files is likely to come up from time to time for various reasons, so some exploration of how do things along those lines is likely to pay off eventually.

[taskwarrior]

Aikido Guy on 2011-09-26T14:25:46Z says:

Where one gives 'move'; one might also give 'copy' :)

How would one move an annotation from a task to become a task itself? Or move a task to become an annotation of another task? Sorry I didn't see your original suggestion! I created #828 and #844.

Perhaps we can move those feature requests to become annotations of your feature request? (Yes, I'm cheeky sometimes)

[taskwarrior]

David Patrick on 2011-09-27T03:53:42Z says:

Aikido Guy wrote:

Where one gives 'move'; one might also give 'copy' :)

a logical extension for sure.

How would one move an annotation from a task to become a task itself? Or move a task to become an annotation of another task? Sorry I didn't see your original suggestion! I created #828 and #844.

that may be well and good, but all of this "a task could become an annotation, and an annotation could become a task" transmogrification is making me a bit queasy! If we sit still in our chairs long enough, it should be come clear again that a task is a task, and annotation are notes attached to tasks, and that is all. Never the twain shall meet, they are different man !

whew

but now that you mention it, I suppose an annotation could spawn a sub-task, if they were used in that way. The reason I might resist using annotations as potential sub-tasks, is that

• in so doing, those sub-tasks loose a serious amount of functionality enjoyed by regular tasks.
• we do not yet have a language to describe which annotations are being referred to, or how taskwarrior might be expected to transform an otherwise free-form and arbitrary annotation, into a real task.
• Annotations are also in danger of becoming overloaded with features, taskopen, tasknote, time tracking, that it's going to need it's own chapter in the docs. etc.

  Perhaps we can move those feature requests to become annotations of your feature request? (Yes, I'm cheeky sometimes)

personally, I think bumping this off to >2.1 is the right thing to do, and we'll figure this out in the spring. (and it's the clever ones you have to look out for ;-)

[taskwarrior]

Aikido Guy on 2011-09-27T14:14:20Z says:

Wasn't trying to make you queasy! here... here's a pill for that :)

Actually, for me, I'm only requesting a very 'simple' thing... if a task has an annotation then I'd like to be able to create a task with a description that is that annotation and then delete the annotation on the original task. I can accomplish the same thing by highlighting my annotation, copying it, creating a new task by pasting the annotation and then editing the original task and deleting the annotation. I was just hoping that this set of steps could be done within TaskWarrior! Of course, I know that the developers have a lot of other work to do too... I was just trying to reduce my own work! yikes! did I just say that? :)

[taskwarrior]

David Patrick on 2011-09-27T14:20:30Z says:

I have the sense that this "annotation to task" function is the sort of thing destined for external script.

% ann2task 117 [ search term ]

Without parameters turns all annotations of 117 into tasks, with [ search term ] turns those annotations of 177 that match, into tasks.

wasn't that easy ?

now alls you gotta do is write it!

ps Aikido Guy, you are hilariously correct in that I'd like to take this annotation of the move command feature request, and move it to it's own task proper. stoopid real world.

[taskwarrior]

Eric Fluger on 2011-09-27T16:30:04Z says:

one of the (several) points of the "record type" idea in the dev ideas format is facilitate exactly this kind of transformation.

[taskwarrior]

Paul Beckingham on 2012-04-16T12:45:50Z says:

Note that this can be achieved with a combination of export and import. This might be enough to reject the issue.

[taskwarrior]

David Patrick on 2012-08-08T18:46:39Z says:

If this action (to pull one or more tasks out of one data file into another) how might that be achieved? I can see how an export/import might result in two copies, but a further step would be needed to remove the source task, once the destination copy is confirmed. Colliding IDs is also another factor here, unless the import function takes care of that.

Is it something I might make an alias for? I have several data files I might merge and/or split.

[taskwarrior]

Paul Beckingham on 2017-01-17T02:54:01Z says:

Equivalent to export/import.