[Ml-yokadi] We should use Keyword in a smarter way

[Aurélien Gâteau]

Sébastien Renard wrote:
>> I do not think it is a good idea: it complicates the parser,
> 
> That's not a nice part. I admit.
> 
>> and add 
>> more than one-way-to-do-it.
> 
> Do you want to remove the -k ?

I would rather revert the change :/. If we want to go for @keyword, then 
I believe we should have a reflexion on our usage of OptionParser. I 
sometimes wonder whether Yokadi would be more usable if it featured a 
natural language.

>> I agree it saves two keystrokes ("@" vs "-k 
>> "), but we could save more by implementing keyword tab completion.
> 
> We do have ;-). Try it with t_list. But it does not work for t_add for now. It 
> needs more work.

Indeed, I miss it for t_add. I just added it to my TODO list.

>>> - project are not mandatory. Yes, we have the default project, but it
>>> could be better.
>> Right now the default project is not very useful: to add a task to the
>> default project one need to create a one word task with "t_add", this
>> does not happen really often. To allow project-less tasks, we would need
>> to make the project name an optional parameter.
> 
> Yes. But the "first word" position of project is a problem for that... And in 
> the other hand, it is a simple solution to manage project. The t_edit make it 
> easy to change project.
> Could we say that project are just a special keyword named project ?

I am not sure I understand what you mean. Early versions of Yokadi did 
not have projects: I thought projects could be implemented as keywords. 
It turned out to be annoying to use... I can't remember why, though.

>>> - allow to add keyword to project, so I can declare a project @work or
>>> @dev or @buy. It save me to put the keyword on each tasks. Every tasks in
>>> the project inherit from project keyword. This will change the database
>>> model. No patch provivded for now, I am waiting for your thought and
>>> approval first.
>> I am not sure I understand. Can you give a more explicit use-case?
> 
> I have some project related to work. I don't want to add keyword "work" to all 
> of tasks in those project. And I would like to make a t_list -u @work
> 
> Same things for dev project or linux or kde project... 
> 
> I could use project hiearchy for that, but that's unidimensional...

OK I see. So "t_list -k work" would list all tasks with the "work" 
keyword and all tasks whose projects have the "work" keyword, am I correct?