From mboxrd@z Thu Jan 1 00:00:00 1970 From: John Hendy Subject: Re: Item task_id not being used in taskjuggler export & tj prefixing Date: Mon, 1 Apr 2013 16:53:28 -0500 Message-ID: References: <87eheutjpz.fsf@gmail.com> <876206th04.fsf@gmail.com> <87wqsmryt0.fsf@gmail.com> <5159F480.3030100@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: Received: from eggs.gnu.org ([208.118.235.92]:34572) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UMmfV-0006QE-5M for emacs-orgmode@gnu.org; Mon, 01 Apr 2013 17:53:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UMmfR-0005r7-Nu for emacs-orgmode@gnu.org; Mon, 01 Apr 2013 17:53:33 -0400 Received: from mail-lb0-f180.google.com ([209.85.217.180]:40761) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UMmfR-0005qx-GL for emacs-orgmode@gnu.org; Mon, 01 Apr 2013 17:53:29 -0400 Received: by mail-lb0-f180.google.com with SMTP id t11so2376353lbi.11 for ; Mon, 01 Apr 2013 14:53:28 -0700 (PDT) In-Reply-To: <5159F480.3030100@web.de> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: buddy.butterfly@web.de Cc: emacs-orgmode On Mon, Apr 1, 2013 at 3:56 PM, Buddy Butterfly 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