emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] Item task_id not being used in taskjuggler export & tj prefixing


From: Christian Egli
Subject: Re: [O] Item task_id not being used in taskjuggler export & tj prefixing
Date: Thu, 25 Apr 2013 09:52:04 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux)

John Hendy <address@hidden> writes:

> On Mon, Apr 1, 2013 at 5:01 PM, Nicolas Goaziou <address@hidden> wrote:

>> You can already do so. IDs only have to be unique within the task
>> siblings.
>
> True, one can name tasks identically as long as they have no identical
> siblings... but the point was the since one can only specify the
> lowest level of id (e.g. "T1" instead of "T.T1"), Org doesn't know how
> to resolve them properly. 

AFAIK task_ids have to be globally unique if you want to use them for
dependencies.

> Task M1 ends up depending on both M.T1 (represented as !T1) /and/
> T.T1. It won't fail since both T.T1 and M.T1 exist, but the user has
> no way to set a depends option to target the specific T1 they wanted.
> Setting =:depends: !!T.T1= ignores the :depends: property entirely.

The TaskJuggler exporter gives you 3 ways to express a dependency:

1. using ORDERED on the parent task
2. using "previous-sibling"
3. using a task_id of another task. This has to be a unique id,
   otherwise you end up depending all the other tasks that have this
   task_id.

>> You don't have to name parents either. You only need to name tasks that
>> will be used as a dependency.
>
> True, which is nice. But we're torn between:
> - Letting Org name the parent whatever it wants, but then having to
> figure out the org-generated parent id so we can do =:depends:
> parent.subtask=, or
>
> - Specifically naming the parent to have control over the task_id, but
> having to change it because we move it later (and then updating all
> =:depends: parent.task_id= properties accordingly)
>
> And in either case, there's still no way to depend on a specific
> =parent.task_id= combination.

I don't understand this. Why do you need to name parents (or assign them
a task_id)? As Nicolas says: all you have to do is to give the task you
want to depend on a task_id. 

As an aside I thought you could also use plain ID to express
dependencies. But from looking at the code this doesn't seem supported.
I think the reason why yet another id (namely task_id) is used, is that
this allows for short human readable ids where as the standard ID is
generally generated by org mode and is cryptic and much longer.

HTH
Christian
-- 
Christian Egli
Swiss Library for the Blind, Visually Impaired and Print Disabled
Grubenstrasse 12, CH-8045 Zürich, Switzerland




reply via email to

[Prev in Thread] Current Thread [Next in Thread]