Bug #153

description replacement broken

Added by Paul Beckingham 399 days ago. Updated 393 days ago.

Status:Assigned Start:06/24/2009
Priority:Normal Due date:
To:Paul Beckingham % Done:

0%
Category:core Spent time: -
Target version:2.0.x - Katana Estimated time:1.00 hour

Description

$ task info 55

Name Value
ID 55
Status Pending
Description implement recurring tasks for freeze protection
6/16/2009 pressure washer, lawn roller, lawn sprayers, faucets
Priority M
UUID 452b55f3-41e0-80e7-2a46-1a6aa024d222
Entered 6/16/2009 (8 days)
$ task 55 implement recurring tasks for season change and freeze protection
Task 55 not found

Related issues

related to Bug #403 Cannot 'task list' search for terms with numbers Assigned 05/03/2010
related to Feature #197 parser upgrade New 07/09/2009

History

Updated by Paul Beckingham 399 days ago

The bug is this:

When parsing a command line, task has to disambiguate between situations such as:

task 1 foo

task foo 1

In your example, the word "recurring" is now the name of a report, and that confused task. I need to do some thinking.

Updated by John Florian 399 days ago

That flexibility is nice, but is too risky? It may also make bash-completions more difficult to implement as well. For example, I'm still working on the completion for projects (#149) and it is very easy to confuse:

task pro<tab>

to mean that you want either "task projects" or "task project:". I'm more worried about what comes after the latter, but a more rigid CLI specification may alleviate much of this.

As for this particular issue, I keep wondering if task should have a special character that indicates what follows is the description. I'd hate typing in "desc:" every time, but something like "task add #this is the description#' wouldn't be so bad. That way we wouldn't need to worry about descriptions that happen to contain task keywords.

Updated by Federico Hernandez 398 days ago

As for this particular issue, I keep wondering if task should have a special character that indicates what follows is the description. I'd hate typing in "desc:" every time, but something like "task add #this is the description#' wouldn't be so bad. That way we wouldn't need to worry about descriptions that happen to contain task keywords.

Not related to this bug but to the bash completion project: would just make sense for certain commands and if one use projects than project: doesn't make sense. One could dynamically append and prune the string containing the completions depending on the already completed "arguments" to task.

Updated by Paul Beckingham 398 days ago

Don't forget that "--" means "stop parsing, and assume everything else is description. So:

task add -- project:foo +tag description /from/to/

adds a task, and the description is:

"project:foo +tag description /from/to/"

Updated by Paul Beckingham 393 days ago

  • Target version changed from 1.8.0 - Kabuto to 2.0.x - Katana

Reassigning to 2.0.0 when the new command line format is to be implemented:

task &lt;id or filter&gt; &lt;command&gt; &lt;modifications&gt;

In the meantime, the workaround is:

task 55 -- implement recurring tasks for season change and freeze protection

Also available in: Atom PDF