[Ml-yokadi] feature request

[Aurélien Gâteau]

David Faure wrote:
> On Tuesday 21 July 2009, Aurélien Gâteau wrote:
>> David Faure wrote:
>>> Hi guys ;)
>>>
>>> Small suggestion for completion:
>>>  t_list @<tab>
>>> shows all keywords, but keywords that are not used anywhere right now
>>> are not useful in t_list (the result will be empty anyway), so the completion would
>>> be cleaner if it only showed keywords that are currently used in an open task.
>>>
>>> Hmm, ok, but with t_list -a it should still show all keywords, maybe that's too
>>> complex for the completion system...
>> I am personally not fond of completion getting too smart. For example I
>> used to get often annoyed when my shell refuses to complete on a tarball
>> because I typed "tar xzf <tab>" and the tarball was actually a tar.bz2
> 
> Well it wouldn't have worked anyway (tar would have given an error message) so better catch the error early, no? ;-)

True, but I always felt like it was broken. Maybe it's just me. Anyway,
unlike "tar xzf file.tar.bz2", "t_list @not_assigned_keyword" is a valid
command, which can be useful.

> My problem is, I don't manage to see at a glance what I have to do, per context.
> Per-project, t_list is fine. But I miss a "show me the tagged tasks, grouped
> by keyword" (excluding internal keyword). E.g. when using keywords as
> contexts (in the GTD meaning of it), I miss a view like
> 
>   @aurelien  (i.e. next time I talk to you)
> 1 foo
> 2 bar
>  @kevin
> 3 foo
> 4 bar
> etc.
> 
> Yes, one could use projects for this, but 1 and 3 might be in the "kde" project,
> while 2 and 4 could be part of another project... The two lists are orthogonal
> ("what remains to be done in this project" and "what should I do in a given
> context, like next time I see kevin"). That's why OmniFocus and zanshin
> have these two views, basically ;-)
> 
> The appearance of keywords in t_list helps a little (thanks for that), but
> not completely (no sorting/grouping per keyword). "t_list @keyword" is
> another partial solution, but it only works if one _remembers_ which keywords
> he has currently stuff for. Doing "t_list @name" for name in { people you know }
> every morning isn't really practical :-)

I see two problems here:
1. You can't run "t_list" for all the people you know.
2. You can't make "t_list" group by keywords instead of projects.


The first problem could be solved if you organized your keywords as a
hierarchies, similar to project hierarchies: something like this:

@people_aurelien, @people_kevin...

What would be needed then is the ability to use wildcards in keywords,
so that you could run "t_list @people_%".


The second problem is more difficult: it is not possible to
automatically decide on the grouping keyword because a task can be
associated with more than one keyword, while it's only associated with
one project.
The solution I suggest would be to say that the first criteria is the
grouping criteria:
- "t_list @people_% kdelibs_%" => list grouped by people
- "t_list kdelibs_% @people_%" => list grouped by kdelibs subprojects

Of course we could add yet-another-option to specify the grouping
criteria, but I think this would be tedious to use.

What do you think about this?