[Ml-yokadi] Using '_' as a shortcut to last task id

Sébastien Renard Sebastien.Renard at digitalfox.org
Sun Oct 11 19:54:10 CEST 2009


Le jeudi 8 octobre 2009 23:05:09, Aurélien Gâteau a écrit :
> Sébastien Renard a écrit :
> > Le mardi 29 septembre 2009 19:00:31, Sébastien Renard a écrit :
> >> Hmm, I though I did it...
> >>
> >>> Maybe it's just github
> >>
> >> Or maybe I was drunk.
> >>
> >> I just push it again and check it on web site. It is ok :
> >> http://github.com/agateau/yokadi/tree/without_glob
> >
> > Should I merge "without_glob" branch into master ?
>
> Sorry, but I don't like it. Having to add support for '_' explicitly
> seems error prone and looks more complicated than having dbutils do the
> work automatically. 

Automagically ;-). It is also error prone if we change dbutils (or don't use 
it), each function have to update the global variable which is quite bad.

I have a better proposition : 
- don't store last id but last task object. Do it at *cmd level.
- dbutils don't have to be aware of that. No change.
- api is light (if not "_" in line : self.task=...)
- we can remember distinct last task, last bug, last notes...

A new branch without_glob2 has been pushed with a first draft of this 
proposition (needs more test and unit test update).

It is more compact that my first proposition and the global option.
Git diff --stat give : 
 3 files changed, 79 insertions(+), 93 deletions(-)

The main drawback is that we have to refer to self.task instead of task which 
is quite more verbose.
It also may lead to error if one day we have a function that call another for 
another task - it will break. But I don't see any usecase for now.

I still don't have found a good solution for the "no previous task" case. Some 
idea:
- store last task when exiting to always have a last task except for an empty 
database

> A proof that it is error prone is that your change
> seems to break bug_edit 

It does not. But t_edit was buggy for another reason, the oldcompleter was not 
restored in some scenario. That's fixed in master.

> (I say "seems" because I still need to figure
> out why github does not want me to pull anymore).

Strange. It works fine here.

-- 
Sébastien


More information about the Ml-yokadi mailing list