Syntax to specify which part of Smart List criteria should be used when tasks inherit properties
torfason says:
Interpret '[' and ']' in searches in the same way as '(' and ')', EXCEPT that if square brackets are present, RTM will ONLY look at the stuff within the square brackets when determining what values to assign to a new task that is being added in a smart list.
I believe this is a good feature because it is:
1: Relatively easy to implement
2: Completely transparent to casual users
3: Very powerful for power users
I believe this is a good feature because it is:
1: Relatively easy to implement
2: Completely transparent to casual users
3: Very powerful for power users
torfason says:
To show that this feature really is powerful, I would like to show a few examples:
1 - A smart list listing all work items that have not yet been classified (classification uses tags starting with °)
CURRENT: "list:work not tagContains:°"
SYMPTOM: "not" makes the list ambiguous, so it just ends up in the inbox, untagged.
SOLUTION: "[list:work] not tagContains:°"
RESULT: Task ends up in list:work (untagged), as it would if the smart list only searched for "list:work"
2 - A smart list which pulls together current actions, as well as any other items that are in need of immediate attention.
CURRENT: "((list:actions OR list:inbox) AND (dueWithin:"2 weeks of today" OR due:never)) OR (dueBefore:today)"
SYMPTOM: Obviously RTM gives up on this, and new tasks end up in the inbox, untagged.
SOLUTION: (([list:actions] OR list:inbox) AND (dueWithin:"2 weeks of today" OR due:never)) OR (dueBefore:today)
RESULT: By bracketing the "list:actions" part, the new task ends up in list:actions, as it would if the smart list only searched for "list:actions"
3 - A second-order smart list combining a hopelessly convoluted smart list and a specific tag (@phone). We would like new tasks to end up in the "actions" list, tagged @phone.
CURRENT: list:MyConvolutedSmartList and tag:@phone
SYMPTOM: RTM chokes on this, since it will not being able to decipher the convoluted list. Simply prepending this with [list:actions and tag:@phone] will not do, because neither an AND nor OR will make the search criteria correct with this addition.
SOLUTION: ([list:actions and tag:@phone] and tag:this.tag.does.not.exist) OR (list:MyConvolutedSmartList and tag:@phone)
RESULT: The new tag will be created to match the bracketed expression, leading the task to be created correctly. However, due to the tag:this.tag.does.not.exist part, the part before the OR will not match anything, and the search expression itself will be completely unchanged. In fact, this method can be used to customize task creation within smart lists in absolutely any way one would like.
1 - A smart list listing all work items that have not yet been classified (classification uses tags starting with °)
CURRENT: "list:work not tagContains:°"
SYMPTOM: "not" makes the list ambiguous, so it just ends up in the inbox, untagged.
SOLUTION: "[list:work] not tagContains:°"
RESULT: Task ends up in list:work (untagged), as it would if the smart list only searched for "list:work"
2 - A smart list which pulls together current actions, as well as any other items that are in need of immediate attention.
CURRENT: "((list:actions OR list:inbox) AND (dueWithin:"2 weeks of today" OR due:never)) OR (dueBefore:today)"
SYMPTOM: Obviously RTM gives up on this, and new tasks end up in the inbox, untagged.
SOLUTION: (([list:actions] OR list:inbox) AND (dueWithin:"2 weeks of today" OR due:never)) OR (dueBefore:today)
RESULT: By bracketing the "list:actions" part, the new task ends up in list:actions, as it would if the smart list only searched for "list:actions"
3 - A second-order smart list combining a hopelessly convoluted smart list and a specific tag (@phone). We would like new tasks to end up in the "actions" list, tagged @phone.
CURRENT: list:MyConvolutedSmartList and tag:@phone
SYMPTOM: RTM chokes on this, since it will not being able to decipher the convoluted list. Simply prepending this with [list:actions and tag:@phone] will not do, because neither an AND nor OR will make the search criteria correct with this addition.
SOLUTION: ([list:actions and tag:@phone] and tag:this.tag.does.not.exist) OR (list:MyConvolutedSmartList and tag:@phone)
RESULT: The new tag will be created to match the bracketed expression, leading the task to be created correctly. However, due to the tag:this.tag.does.not.exist part, the part before the OR will not match anything, and the search expression itself will be completely unchanged. In fact, this method can be used to customize task creation within smart lists in absolutely any way one would like.
torfason says:
Two additions to my previous idea:
1 - Instead of "[]", use "(())" (double parenthesis), to delineate the part that should be used when adding new task. This would make all the expressions currently legal search expressions, so the only change would be a simple if statement and a string replace in the code for adding a task.
2 - This feature actually includes default due dates - for free. Prepend any smart list definition with:
(((due:today)) AND tag:nonexistant) OR
and all tasks made in that smart list will be entered as due today.
This seems like extremely low hanging fruit. Will we see it implemented? Here's hoping!
1 - Instead of "[]", use "(())" (double parenthesis), to delineate the part that should be used when adding new task. This would make all the expressions currently legal search expressions, so the only change would be a simple if statement and a string replace in the code for adding a task.
2 - This feature actually includes default due dates - for free. Prepend any smart list definition with:
(((due:today)) AND tag:nonexistant) OR
and all tasks made in that smart list will be entered as due today.
This seems like extremely low hanging fruit. Will we see it implemented? Here's hoping!
Log in
to post a reply.