From mboxrd@z Thu Jan 1 00:00:00 1970 From: Buddy Butterfly Subject: Re: Item task_id not being used in taskjuggler export & tj prefixing Date: Thu, 04 Apr 2013 15:59:48 +0200 Message-ID: <515D8754.3040304@web.de> References: <87eheutjpz.fsf@gmail.com> <876206th04.fsf@gmail.com> <87wqsmryt0.fsf@gmail.com> <5159F480.3030100@web.de> Reply-To: buddy.butterfly@web.de Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Return-path: Received: from eggs.gnu.org ([208.118.235.92]:39446) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UNkhq-0005sp-Rl for emacs-orgmode@gnu.org; Thu, 04 Apr 2013 10:00:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UNkhk-0007Z9-7f for emacs-orgmode@gnu.org; Thu, 04 Apr 2013 09:59:58 -0400 Received: from h1359005.stratoserver.net ([81.169.136.31]:51692) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UNkhj-0007Yk-Qb for emacs-orgmode@gnu.org; Thu, 04 Apr 2013 09:59:52 -0400 In-Reply-To: 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: John Hendy Cc: emacs-orgmode 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 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