Add remaining, to be consolidated FAQs

content/support/faq/faq.101.md

@@ -0,0 +1,19 @@
+---
+title: "Taskwarrior - FAQ"
+---
+
+Q: Filter only pending tasks
+
+I thought about using a virtual tag, but there is nothing like `+PENDING`.
+
+I have lots of recurring tasks that I want to delete in batch, but `task <taskname>` returns the completed ones, too and I don’t want to delete these.
+
+A: A `+PENDING` virtual tag is a good idea. It would make a nice feature request.
+
+A: Please try
+
+```
+task status:pending all
+```
+
+A: It is worth noting that most reports already have a filter that already includes `status:pending`, but the `all` report used here as an example has no filter, which makes it useful as an example like this.

content/support/faq/faq.102.md

@@ -0,0 +1,11 @@
+---
+title: "Taskwarrior - FAQ"
+---
+
+### Q: How can I filter by project for the timesheet command?
+
+As far as I can tell, `task timesheet` has no way to filter which projects are reported on.
+The obvious `task proj: projname timesheet` doesn't work.
+
+A: Sorry, the timesheet command does not support filters, and I think it should.
+This would make a good feature request.

content/support/faq/faq.103.md

@@ -0,0 +1,18 @@
+---
+title: "Taskwarrior - FAQ"
+---
+
+Q: Why are virtual tags better than direct attribute comparisons?
+
+(Great question copied from support email)
+
+For example, why should I do this:
+
+$ task +WEEK list
+Instead of:
+
+$ task due.after:sow and due.before:eow list
+It's shorter, but is it better?
+
+A: It's better because it is fewer character to type, and therefore less prone to error.
+But it is identical.

content/support/faq/faq.104.md

@@ -0,0 +1,9 @@
+---
+title: "Taskwarrior - FAQ"
+---
+
+Q: How does `task log Do something` affect done/delete ratio?
+
+A: "task log Did something" would create the task and mark it completed in one step.
+
+It would affect your done/deleted ratio by adding one to the "done" (completed) pile.

content/support/faq/faq.105.md

@@ -0,0 +1,14 @@
+---
+title: "Taskwarrior - FAQ"
+---
+
+Q: How can I find the parent of a recurring task if no child is left?
+
+A: I think he means to find the recurring task if there are not any children with status pending.
+
+A: You can use the following to list all the parents:
+
+task all status:recurring
+You can add more search terms as usual. For example, to find the recurring task to change your brita water filter:
+
+task all status:recurring brita

content/support/faq/faq.106.md

@@ -0,0 +1,24 @@
+---
+title: "Taskwarrior - FAQ"
+---
+
+Q: How can I denotate all annotations at once?
+Neither
+```
+task denotate "*" 123
+```
+nor
+```
+task denotate * 123
+```
+work for the task with id 123.
+
+A: There is currently to way to remove annotations in bulk other than using:
+
+```
+task <taskid> edit
+```
+and removing all the annotation lines.
+
+You could also write a helper script to remove all annotations.
+Using the export command will make it easier to parse.

content/support/faq/faq.107.md

@@ -0,0 +1,57 @@
+---
+title: "Taskwarrior - FAQ"
+---
+
+Q: How can I track my 'not to be done' list?
+
+A: As far as I know taskwarrior has no status that represents "not to be done".
+In practice most people simply delete tasks that are no longer valid.
+
+Still, you can use existing functionality to provide such feature.
+
+One possibility is to set the task waiting till the end of days:
+
+```
+task add wait:someday Buy a private spaceship
+```
+
+Technically this would be waiting until 1/18/2038, but you get the idea.
+
+An alternative would be to create a project that holds all your "not to be done" tasks and that is never displayed in your default reports:
+
+```
+task add proj:wontdo "Do yesterday's dinner"
+```
+
+and then simply add:
+
+```
+default.command=next proj.not:wontdo
+```
+
+to your .taskrc file, or any variation using your preferred report.
+
+Then when you want to see these tasks, a simple:
+
+```
+task all proj:wontdo
+```
+
+will do.
+
+Another possibility is to create a TAG and explicitly filter based on presence or absence of said TAG:
+
+```
+task add +wontdo "Travel back in time to tell myself I was wrong"
+```
+
+and apply the same principle to the default command in .taskrc:
+
+```
+default.command=next -wontdo
+```
+
+Given all these possibilities, choose the one that you find easier to use and best suits you.
+
+PS: There may be better ways to specify default options.
+I need to dig into that subject myself.

content/support/faq/faq.108.md

@@ -0,0 +1,19 @@
+---
+title: "Taskwarrior - FAQ"
+---
+
+Q: How can I assign a task to a project while creating the task?
+For instance I recently did :
+
+```
+$ task project:todaysproject add pick up laundry
+```
+
+however when I list all tasks it shows that the task is not assigned to a project.
+
+A: The "project:todaysproject", when it appears before the "add" command is ignored.
+Try putting the command first:
+
+```
+$ task add project:todaysproject pick up laundry
+```

content/support/faq/faq.109.md

@@ -0,0 +1,68 @@
+---
+title: "Taskwarrior - FAQ"
+---
+
+Q: How do I remove duplicate UUIDs?
+
+If the command:
+
+```
+$ task diag
+...
+```
+
+states that there are duplicate UUIDs, how do I remove them?
+
+A: As far as I know there is no automated way to deal with duplicate UUIDs.
+
+What follows is what I would do (did) in this situation.
+
+The first thing you should do if task diag identifies one or more tasks with the same UUID is to list those tasks by using the UUID.
+If your UUID was 42687c6e-a5c5-45be-a6f5-5c26006abf24 then do:
+
+```
+task 42687c6e-a5c5-45be-a6f5-5c26006abf24 info
+```
+
+If they are identical it's likely that they got corrupted.
+In this situation the only thing left to do is to "get rid" of the duplicates until there is none that is identical.
+Read on how to fix them below.
+
+If the matching tasks are different, it's possible that they are still salvageable by assigning a new UUID that is not yet used. 
+
+Fixing duplicates:
+
+Because taskwarrior uses UUIDs internally to match tasks, you won't be able to edit one task without affecting the other with same UUID.
+In fact the first task found with given UUID will receive all changes.
+
+In general editing your .data files by hand is not recommended.
+This is probably the one and only exception.
+
+With that said, make a backup of all the files in your $HOME/.task folder.
+Then open all your .data files in a text editor (gedit, vim, emacs... not openoffice or such), search for the UUID using the editor's find function.
+
+In the case that the tasks are identical, simply remove one of them by deleting the whole line, until there are no more duplicates.
+Save and run task diag again for confirmation.
+
+If on the other hand tasks are different, first find a UUID that is not taken.
+Start by incrementing or decrementing the rightmost number.
+Then confirm that no such UUID exists by running:
+
+```
+task NEW-UUID all
+```
+
+Once you are positive, change the UUID of one of the duplicate tasks by replacing it with the NEW-UUID.
+
+Repeat until no more duplicates exist.
+
+Wrapping up
+
+Now, if these duplicates have already been synced, you will also need to correct the database on taskd as well as on other clients.
+
+Taskd should have mechanisms in place to prevent creating tasks with duplicate UUIDs.
+This information requires confirmation.
+
+As far as I know the duplicate UUID problem cannot be solved by manually crafting entries in the backlog.data file.
+
+I never had to go this far, but I can only envision a road with a lot of pain!

content/support/faq/faq.110.md

@@ -0,0 +1,30 @@
+---
+title: "Taskwarrior - FAQ"
+---
+
+Q: How to set 'wait' until one day before 'due'?
+Construction:
+
+```
+task 1 modify wait:due-1days
+```
+
+unfortunately doesn't work.
+
+A: Currently date expressions are not supported.
+This means instead of:
+
+```
+wait:due-1days
+```
+
+You have to calculate 'due-1days' yourself.
+
+Beginning with taskwarrior 2.4.0, date expressions will be supported, and exactly what you described will just work.
+Additionally, algebraic expressions will be supported in several places.
+Here is an example from the dev branch, using the new 'calc' command:
+
+```
+$ task calc 20140430 - 1days
+2014-04-29T00:00:00
+```

content/support/faq/faq.111.md

@@ -0,0 +1,40 @@
+---
+title: "Taskwarrior - FAQ"
+---
+
+Q: Sync not working!
+Hello!
+
+I have installed task from Ubuntu repositories.
+
+task --version returns 2.2.0.
+I want to sync it with the taskserver made available by mirakel.
+So, I have added these lines to ~/.taskrc:
+
+taskd.server=azapps.de:6544
+taskd.credentials=XXXXXXXXXXXX
+taskd.certificate=/home/YYYYYY/.task/client.pem
+taskd.ca=/home/YYYYYY/.task/ca.pem
+taskd.key=/home/YYYYYY/.task/client.key.pem
+But task sync produces the error:
+
+$ task sync
+[task next sync]
+No matches.
+task show produces the error:
+
+Your .taskrc file contains these unrecognized variables:
+  taskd.ca
+  taskd.certificate
+  taskd.key
+Obviously, I am doing something wrong. But I am not able to figure out the error even after reading the documentation.
+
+Also, there is no 'Register' link on the Q&A forum. I could not ask this question there.
+
+Please let me know if you need any further information to troubleshoot.
+
+A: The sync command was only introduced in task 2.3.0.
+
+The reason you are getting those errors is because task 2.2.0 didn't have those settings.
+
+As for why it didn't complain about the sync command, it's because it was treated as a filter, effectively listing only tasks that have "sync" in the description.

content/support/faq/faq.112.md

@@ -0,0 +1,61 @@
+---
+title: "Taskwarrior - FAQ"
+---
+
+Q: How do recurring tasks work?
+How do recurring tasks work?  (A guide to recurring tasks)
+
+A: This guide is written for task version 2.3.0.
+
+Due to inconsistencies and general lack of documentation, I thought it would be useful to write this, both as a personal reference and for others who need it.
+
+General Info
+First, you should read this: https://taskwarrior.org/docs/recurrence.html  It covers some basic information about recurring tasks.
+
+The mental model you should be working with is that, when you create a recurring task, you create a template from which little children task instances are spawned.
+taskwarrior uses the due, recur, mask, and until fields to determine when to spawn children task instances.
+
+Change Propagation
+This is one of the key ambiguities to understand when working with recurring tasks.
+Currently, taskwarrior has certain bugs that contribute to this (See  TW-1293 - Modifying or deleting a child task does not propagate if there are no siblings RESOLVED  and   TW-1294 - Modifying a child task does not propagate to parent RESOLVED  ).
+
+Modifying a child task
+When you modify a child task (includes the commands modify, prepend, append, annotate, and possibly others), taskwarrior will check if there are other child tasks (sibling tasks).
+If there are, task will ask whether or not to propagate the changes to the other tasks.
+if you choose yes, the changes will be propagated to the sibling tasks, but NOT to the parent task.
+This means that child tasks that are spawned in the future will not have these changes.
+
+If you want to change all child tasks, including future ones, you should instead modify the parent task template.
+
+Modifying a parent task
+When you modify a parent task, the changes will be applied to the parent task.
+If there are any children, you will be asked whether or not to propagate the changes, and if you choose yes, the changes will be propagated as expected.
+However, there is a special case (see next section).
+
+Changing recurrence period or start date
+Due to how taskwarrior tracks the spawning of child tasks (using due, recur, mask, and until fields), trying to modify these attributes on the parent task template directly will result in weird behavior.
+Thus, if you want to change due or recur (the start date or recurrence period), the best approach is to duplicate the parent task template, applying any needed changes, then delete the original task template.
+This will also reset the mask on the new parent task, so taskwarrior knows what child tasks it needs to spawn.
+
+Deleting a child task
+This is almost identical to modifying a child task (see above), HOWEVER, if you choose to propagate the deletion, the parent task WILL also be deleted, unlike with modifications.
+Note that this prompt to propagate only appears if there are sibling tasks (i.e., at least one other child task, or more than one child task all together), so it is not a reliable way of deleting or stopping a recurring task template.
+
+Deleting a parent task
+You can't do it directly.
+The best way would be to modify the until field to a suitable date (try -1d if you're feeling lazy).
+If there are any child tasks, you will be asked to propagate the changes, as per the modifying parent tasks section above.
+Child tasks who have passed their until date will be expired and deleted.
+
+However, the parent task template will not be expired and deleted, though it will stop spawning children tasks.
+That means that parent task "zombies" can accumulate in your tasks files, increasing task ID numbers and generally taking up room.
+You can periodically clean up these tasks by running 
+
+task status:recurring until.before:today ids
+to get a list of IDs of dead parent tasks.
+Actually removing the tasks is left as an exercise for the reader (since you can't delete them with taskwarrior, remember?).
+
+Ideas to try: write a script to delete the lines from ~/.task/pending.data, or delete the lines manually (ID numbers correspond to line numbers in pending.data.
+Make sure you delete from the bottom up so the line numbers don't shift as you are working.)
+
+You can use this script to clean up expired task templates: https://gist.github.com/darkfeline/7d138198b68271a9f6fe  Read the code to see what it does, and modify it if needed.