From: Buddy Butterfly <buddy.butterfly@web.de>
To: John Hendy <jw.hendy@gmail.com>
Cc: emacs-orgmode <emacs-orgmode@gnu.org>
Subject: Re: Item task_id not being used in taskjuggler export & tj prefixing
Date: Thu, 04 Apr 2013 15:59:48 +0200 [thread overview]
Message-ID: <515D8754.3040304@web.de> (raw)
In-Reply-To: <CA+M2ft9PEoKgq-BvrK7s=N1s=r3F05tBN0fHSk3LaWZRmEJa2w@mail.gmail.com>
Hi John,
regarding your "potential" IRC date with Christian Egli, I would like
to join, if I*ll find the time. For when is it scheduled? I have also posted
a base for discussion here on the list.
Thanks and best regards,
Matt
Am 01.04.2013 23:53, schrieb John Hendy:
> On Mon, Apr 1, 2013 at 3:56 PM, Buddy Butterfly <buddy.butterfly@web.de> wrote:
>> Hi,
>>
>> regarding your example
>>
>> ** Milestones :M:
>> *** Task
>> :PROPERTIES:
>> :task_id: M2
>> :depends: T8
>> :END:
>>
>> ** Technical :T:
>> :PROPERTIES:
>> :task_id: T
>> :END:
>> *** Task
>> :PROPERTIES:
>> :task_id: T8
>> :duration: 1d
>> :END:
>>
>>
>> I would like to discus what I mean with a prefix.
>> At the moment oex tries to mirror some functionality of
>> tj to org mode. From an architectural point of view I
>> would do this only for few selected functionalities.
>> Otherwise you developers have to always adapt code to
>> tj. If you would implement generic tj properties that
>> will be exported as is, then one could easily write
>> the tj stuff itself.
>>
>> The problem becomes obvious with your example above.
>> Herr you expect that T8 would be unique across all
>> tasks. If there are some other task paths with a task of
>> T8 then this will not work. You will always run after
>> tj implementing what they have implemented. Why not
>> write:
>>
>> :depends: !!T.T8
>>
>> directly? This is what should be done. Leave the tj
>> logic to tj and do not try to map it to org-mode.
>> The more you map the more difficult to maintain, etc.
>>
> I agree and would prefer this. Especially since folks wanting to
> export and being allowed to access tj functionality through drawers
> are probably going to anticipate using actual tj syntax in those
> drawers. Since tj only forces unique global ids (one can have M.T8,
> T.T8, etc.), this would solve the issue of ambiguity should one decide
> to use non-globally unique task ids. In fact, many projects may very
> well use a lot of repetitive tasks with the same properties.
>
> In mine, I have some tasks regarding shipping products to various
> countries. This way I could just have a bunch of country-specific
> headlines like:
>
> * Country
> ** Ship product
>
> * Country 2
> ** Ship product
>
> And could give all the ** Ship... tasks the same id since their
> Country parent would make it globally unique.
>
> For now, I'm just happy to have functionality restored so I can use
> Org and not hand-edit the files after exporting :) I have a potential
> IRC date with Christian Egli sometime this week... perhaps you should
> join and add your feedback? One of my other points of input would be
> that something like C-c l (Org store link at point) would be great.
> Unique ids could be inserted as depends with some simple key strokes
> and I would't have to use numbered IDs at all. They'd stay with the
> tasks no matter where I moved them.
>
> For that... I'd actually prefer *not* to have to explicitly name the
> parent since they could move wherever I put them with no consequence.
>
>
> John
next prev parent reply other threads:[~2013-04-04 14:00 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-01 0:04 Item task_id not being used in taskjuggler export John Hendy
2013-04-01 0:16 ` John Hendy
2013-04-01 0:44 ` John Hendy
2013-04-01 14:21 ` Nicolas Goaziou
2013-04-01 14:53 ` John Hendy
2013-04-01 15:20 ` Nicolas Goaziou
2013-04-01 16:00 ` John Hendy
2013-04-01 16:38 ` Nicolas Goaziou
2013-04-01 16:57 ` John Hendy
2013-04-01 17:05 ` Nicolas Goaziou
2013-04-02 3:27 ` John Hendy
2013-04-01 20:56 ` Item task_id not being used in taskjuggler export & tj prefixing Buddy Butterfly
2013-04-01 20:59 ` Buddy Butterfly
2013-04-01 21:53 ` John Hendy
2013-04-01 22:01 ` Nicolas Goaziou
2013-04-02 3:24 ` John Hendy
2013-04-25 7:52 ` Christian Egli
2013-04-04 13:59 ` Buddy Butterfly [this message]
2013-04-24 20:09 ` Christian Egli
2013-04-24 19:51 ` Christian Egli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=515D8754.3040304@web.de \
--to=buddy.butterfly@web.de \
--cc=emacs-orgmode@gnu.org \
--cc=jw.hendy@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).