John Hendy writes:
> On Mon, Apr 1, 2013 at 5:01 PM, Nicolas Goaziou 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
John Hendy writes:
> 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
Buddy Butterfly writes:
> 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.
True, task_ids have to be unique across tasks. For me this was never a
pr
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:
On Mon, Apr 1, 2013 at 12:05 PM, Nicolas Goaziou wrote:
> John Hendy writes:
>
>> Process:
>> - Save your patch to ~/Downloads/patch.patch
>> - cd ~/.elisp/org.git
>> - git branch tj-test
>> - git checkout tj-test
>> - patch -p1 < ~/Downloads/patch.patch
>> - make clean && make
>> - start fresh E
On Mon, Apr 1, 2013 at 5:01 PM, Nicolas Goaziou wrote:
> John Hendy writes:
>
>> 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.
John Hendy writes:
> 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.
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
>
Correction, see below...
Am 01.04.2013 22:56, schrieb Buddy Butterfly:
> Hi,
>
> regarding your example
>
> ** Milestones :M:
> *** Task
> :PROPERTIES:
> :task_id: M2
> :depends: T8
> :END:
>
> ** Technical :T:
> :PROPERTIES:
> :task_id: T
> :END:
>
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
John Hendy writes:
> Process:
> - Save your patch to ~/Downloads/patch.patch
> - cd ~/.elisp/org.git
> - git branch tj-test
> - git checkout tj-test
> - patch -p1 < ~/Downloads/patch.patch
> - make clean && make
> - start fresh Emacs session
Dismiss the patch. I pushed the changes into master. Y
On Mon, Apr 1, 2013 at 11:38 AM, Nicolas Goaziou wrote:
> John Hendy writes:
>
>> On Mon, Apr 1, 2013 at 10:20 AM, Nicolas Goaziou wrote:
>>> John Hendy writes:
>>>
I still have the issue of depending on a task not in the current
subtree, but perhaps I'm just not using the exporter co
John Hendy writes:
> On Mon, Apr 1, 2013 at 10:20 AM, Nicolas Goaziou wrote:
>> John Hendy writes:
>>
>>> I still have the issue of depending on a task not in the current
>>> subtree, but perhaps I'm just not using the exporter correctly:
>>
>> There was indeed a bug in the dependencies formatt
On Mon, Apr 1, 2013 at 10:20 AM, Nicolas Goaziou wrote:
> John Hendy writes:
>
>> I still have the issue of depending on a task not in the current
>> subtree, but perhaps I'm just not using the exporter correctly:
>
> There was indeed a bug in the dependencies formatting. It should now be
> fixed
John Hendy writes:
> I still have the issue of depending on a task not in the current
> subtree, but perhaps I'm just not using the exporter correctly:
There was indeed a bug in the dependencies formatting. It should now be
fixed in master. Could you confirm it?
> *** Task
> :PROPERTIES:
>
On Mon, Apr 1, 2013 at 9:21 AM, Nicolas Goaziou wrote:
> Hello,
>
> John Hendy writes:
>
>> I seem to be having trouble getting custom task_id values used for my
>> taskjuggler file.
>
> Thank you for the detailed report. Would the attached patch fix the
> problem?
>
Thanks for the quick respons
Hello,
John Hendy writes:
> I seem to be having trouble getting custom task_id values used for my
> taskjuggler file.
Thank you for the detailed report. Would the attached patch fix the
problem?
Regards,
--
Nicolas Goaziou
>From 30b8328292fc09b3f1ae84b469d1c574c19bfa58 Mon Sep 17 00:00:00 2
On Sun, Mar 31, 2013 at 7:16 PM, John Hendy wrote:
> On Sun, Mar 31, 2013 at 7:04 PM, John Hendy wrote:
>> I seem to be having trouble getting custom task_id values used for my
>> taskjuggler file. From ox-taskjuggler.el:
>>
>> #+begin_quote
>> (defun org-taskjuggler--build-task (task info)
>>
On Sun, Mar 31, 2013 at 7:04 PM, John Hendy wrote:
> I seem to be having trouble getting custom task_id values used for my
> taskjuggler file. From ox-taskjuggler.el:
>
> #+begin_quote
> (defun org-taskjuggler--build-task (task info)
> "Return a task declaration.
>
> TASK is a headline. INFO is
I seem to be having trouble getting custom task_id values used for my
taskjuggler file. From ox-taskjuggler.el:
#+begin_quote
(defun org-taskjuggler--build-task (task info)
"Return a task declaration.
TASK is a headline. INFO is a plist used as a communication
channel.
All valid attributes fr
20 matches
Mail list logo
