emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: John Hendy <jw.hendy@gmail.com>
To: buddy.butterfly@web.de
Cc: emacs-orgmode <emacs-orgmode@gnu.org>
Subject: Re: Item task_id not being used in taskjuggler export & tj prefixing
Date: Mon, 1 Apr 2013 16:53:28 -0500	[thread overview]
Message-ID: <CA+M2ft9PEoKgq-BvrK7s=N1s=r3F05tBN0fHSk3LaWZRmEJa2w@mail.gmail.com> (raw)
In-Reply-To: <5159F480.3030100@web.de>

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

  parent reply	other threads:[~2013-04-01 21:53 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 [this message]
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
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='CA+M2ft9PEoKgq-BvrK7s=N1s=r3F05tBN0fHSk3LaWZRmEJa2w@mail.gmail.com' \
    --to=jw.hendy@gmail.com \
    --cc=buddy.butterfly@web.de \
    --cc=emacs-orgmode@gnu.org \
    /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).