The word 'history' in issue description can expand to 'history.monthly'

[tbabej]

As discovered in https://github.com/vit-project/vit/issues/295:

# task add this is a history lesson
Created task 1.
# task list

ID Age  Description                          Urg 
 1 3s   this is a history.monthly lesson        0

1 task

Reproduced on 2.6.0.

[tbabej]

Note that I was not successful with partial ghost-completion of other commands, so it looks like the presence of the dot is crucial here.

[smemsh]

is this not expected behavior? after all, we have:

task add -- this is a history lesson
task add "this is a history lesson"

man page directs use of this method:

The argument -- (a double dash) tells Taskwarrior to treat all other args as description

it seems like taskwarrior tries to find something meaningful in each of its args, so this may not be unexpected if user is not quoting or indicating end of "non description" args

[tbabej]

I'd consider this expected if the add command was not specified, but if it is, it really can take users (especially history students :sweat_smile: ) by surprise.

If add was not specified, then task should interpret history as history.monthly command and rest of the words as best it can, in this case it would be a description filter.

The two commands that you posted are perfectly correct workarounds for this issue though!

[smemsh]

So 'add' changes semantics? It's still looking for other significant words in the arguments, that aren't a description, such as project:foo or +tag, right? How can Taskwarrior magically know what words it shouldn't consider? The user has to know Taskwarrior syntax, that he should quote or -- the description if it contains words significant to Taskwarrior. Today it's history, tomorrow it's whatever.

In vit/application.py it looks like they're just passing the words bare to "task add" or "task N mod", so it's actually up to the user to know they would have to quote properly if they want it to be a description. The VIT UI could prompt for a description and "other stuff" as separate inputs for example, and use the proper quoting. If not, rely on user to know taskwarrior syntax.

anyways it's an academic point mostly

[acrobertson]

is this not expected behavior? after all, we have:

task add -- this is a history lesson
task add "this is a history lesson"

I did not expect this behavior, which is why I'm here! I was going to file an issue but found this one. Just thought I could add some context for why I would consider this a bug.

Here's the very first example in the Getting Started page from the docs:

task add Prepare the first draft of the proposal due:friday

The vast majority of the examples throughout the docs include the description plainly in the command, with no quotes or flags.

I did read the docs for the add command, which say:

You can also provide quoted strings. [...] It is a good idea to quote task descriptions to avoid some problems with the shell, although not necessary. [...] Dealing with shell issues is covered in detail in the Escaping Shell Characters page.

This makes me think, "OK, if I have any special characters in my description, I should wrap it in quotes; otherwise, it should be fine to enter without." There's no mention of particular keywords that should be avoided.

How can Taskwarrior magically know what words it shouldn't consider?

This is definitely a tough problem! It seems to me like anything after the add argument should be parsed as description unless it's formatted as key:value, but I'm sure there's some additional complexity I'm unaware of. That's just what I was expecting as a (relatively new) user.

In the meantime, I'll just be quoting all my descriptions from now on, to be safe.