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

[Frederic JECKER]

Hi all,

I'm a long time pythonista, *nix addict and CTO of a java developpement team
working on a healthcare
system based on an apple framework named WebObjects.

I'm intensively using yokadi for a few days now (since the post on
linuxfr.org), and I found it very very useful.

I think that Aurelien is right when he says "Yokadi would be more usable if
it featured a
natural language".

In my usage, I always have yokadi opened on one of my screens, in order to
log some work items while developping. The quicker the task is logged, the
quicker I can go back to my developpments?

Logging tasks using natural language would be great, I already started to
think about it, I will post some more thoughts a little later.

Just an exemple, logging some work items :
Add task Refactor javadoc comments on class ZZZ to project Medical file.

In this case this would trigger the command do_add, extract the first word
to check the kind of data the user wishes to add (task, project, bug).
The problem here will be the project definition, the "to" keyword is
commonly used and would turn impossible an accurate data extraction of the
project name. It could  be replaced by a camelcased keyword like
"toProject", this will also allow multi word project name.
This could easily be achieved using regexp, to match instructions and to
extract the data.

Thanks for this good little piece of software

Regards

FJ



On Tue, Feb 10, 2009 at 10:56 PM, Aurélien Gâteau
<aurelien.gateau>wrote:

> 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?
> _______________________________________________
> Ml-yokadi mailing list
> Ml-yokadi
> http://sequanux.org/cgi-bin/mailman/listinfo/ml-yokadi
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: http://sequanux.org/pipermail/ml-yokadi/attachments/20090211/56e3a7c8/attachment.htm