Re: [O] [PATCH] Add 'inline-only option to org-export-babel-evaluate

[Nicolas Goaziou]

Hello,

Aaron Ecay  writes:

> * lisp/ob-exp.el (org-export-babel-evaluate): Update defcustom to
>   provide 'inline-only option
>   (org-babel-exp-results): Implement 'inline-only for
>   org-export-babel-evaluate
>
> This is useful because there is no way for inline results to be stored.
> The imagined usecase is that all non-inline source blocks will be
> evaluated manually by the user.

I'll let Eric decide about the usefulness of this.

> Inline blocks, however, must be evaluated during export, or they will
> be simply deleted by the exporter.

This sentence is wrong. Look, for example at
`org-latex-inline-src-block'. The exporter doesn't delete anything,
Babel does.


Regards,

-- 
Nicolas Goaziou

Re: [O] [PATCH] Properly escape ~ for LaTeX export

[Nicolas Goaziou]

Hello,

Aaron Ecay  writes:

> * lisp/ox-latex.el:
> (org-latex-plain-text): Properly escape ~ for LaTeX export

Applied. Thank you.


Regards,

-- 
Nicolas Goaziou

Re: [O] [BUG] [ODT] Subtree export gives wrong footnote style

[Nicolas Goaziou]

Hello,

Christian Moe  writes:

> * The new styles don't seem to get applied
>
> Quote and center blocks in footnotes do not get OrgFootnoteQuotations
> style in my test. They remain Footnote.
>
> (You didn't add any OrgFootnoteVerse style, but I tried it out anyway. A
> verse block inside a footnote appears as OrgVerse.)
>
> I include below a test Org fragment and attach the resulting ODT.

Judging by the output (i.e. contents.xml), styles are applied:

  “I see that it is long”, said 
Alice, “but how can a tail be sad?”
  

  Centered text here.
  

The question is: why aren't these styles effectively applied on the
output. It may be related to their definition, which can be incorrect.


Regards,

-- 
Nicolas Goaziou

Re: [O] [PATCH 0/3] synctex support for pdf export

[Nicolas Goaziou]

Hello,

Aaron Ecay  writes:

> This patch series is an attempt to add synctex support to org mode.

Thank you for your patch.

> I have not tested this code extensively, but it does work for me.  I
> don't know if it works for async export or not, since I haven't set up
> a working environment for that.

Async export works out of-the-box (though not optimized). There's no
special environment to set up.

> There are currently limitations.  The granularity of the jumping is
> not great, because of the way the parser works.  It will get you into
> the paragraph corresponding to the PDF location, but no closer (with
> pure latex, you will arrive at the exact line in the tex file).  You
> also have to run org-latex-patch-synctex manually, unless you use the
> direct-to-pdf export option (C-c C-e l p).  In regular latex, beamer
> documents have somewhat degraded synctex granularity (in general, you
> don't get to the exact source line, but only somewhere between
> \begin{frame} and \end{frame}).  This may be compounded by the bad
> granularity of this patch -- I have not tested this combo very much.

[...]

As you notice, there are many limitations and I agree some of them will
be tedious to overcome. It also breaks asynchronous export.

Moreover, modifying both parser and core export framework for an
optional feature within a single back-end family is not right, IMO.

While I acknowledge the investment put into this patch, I won't accept
it in its current form. I might consider it if it only modifies
ox-latex.el, handles include keywords and buffer modifications through
Babel, and doesn't break asynchronous export. Not relying on text
properties is a real plus.

Though, don't push it too hard, I'm really not sure it's worth the
trouble.


Regards,

-- 
Nicolas Goaziou

[O] Visibility cycling bugs when an org file ends with a plain list

[James Harkins]

Hi,

I don't remember if this was reported or not. I frequently get the
following message in the mini-buffer, after trying to expand the last
top-level node in a file. The behavior seems to depend on the last
node containing a plain list.

byte-code: Invalid search bound (wrong side of point)

This issue occurs if org-cycle-include-plain-lists is set to
'integrate'. If I change it back to the default 't', then I get a
different incorrect behavior.

Example (with org-cycle-include-plain-lists = integrate):

~~ Contents
* I
** A
* II
** B
   - Plain list
~~

Hit shift-tab to collapse everything:

~~ Visible contents
* I...
* II...
~~

Now put the insertion point anywhere on "* II" and hit tab to expand
the sub tree. Here's where I get that message.

The normal behavior of TAB visibility cycling is:

TAB once: Expand to show the node's immediate children, but the
children are collapsed.
TAB again: Expand everything underneath the current node.
TAB again: Collapse, to show only the current node.

When I get the message, I only get #1 and #3 behaviors. I can't hit
TAB twice on the heading to see everything underneath.

Now, if org-cycle-include-plain-lists = t, hitting TAB twice does
expand the plain list, but unfortunately it will not display the last
character:

~~ Result of TABx2 with the point on "* II"
* I...
* II
** B
   - Plain lis...
~~

I haven't found a keystroke that will make "t" of "list" reappear. "t"
is actually still there (copy and paste will demonstrate that), but
the visibility code seems to think that something at the end is
supposed to be hidden, even if just one character.

Org-mode version 8.0-pre (release_8.0-pre-215-g8ccbc7 @
/home/dlm/share/org-mode.git/lisp/)

Thanks,
hjh

[O] Org as a static site generator

[David Engster]

I'd like to use Org as a static site generator. I know quite a few
people use Org to manage their sites, so I'd like to know what's already
available and what I'd need to add to make this working properly.

I know of course how to export a bunch of Org files to HTML through the
publishing features. However, that's not really cutting it, I'm afraid.

Thing of a typical HTML5 template having a , , ,
and . I'd like Org to include the different exported files into
the  section, and the rest to remain the same. The  would
contain a global navigation menu, also highlighting the current active
section (though CSS, no JS please).

Has anybode done something like this?

-David

Re: [O] Org as a static site generator

[Vincent Beffara]

Hi,

I am using o-blog for that, it is pretty great. One Org file for everything, 
and it actually splits it into one page per marked headline. You can use one of 
the headlines as a template for the nav section of the page, shared across all 
pages. (As you can tell from the name, it is intended as a blogging tool, but 
you don't have to use it that way ...)

The default template might not be to your taste (I don't like it at all, 
personally, so I made my own essentially from scratch) but you can customize it 
easily enough. And it might actually be close to what you are looking for.

Page: http://perso.ens-lyon.fr/vincent.beffara/
Source: https://www.dropbox.com/sh/kdu6myi2ov7y78e/3Ljz5Eipq9
> Thing of a typical HTML5 template having a , , ,
> and . I'd like Org to include the different exported files into
> the  section, and the rest to remain the same. The  would
> contain a global navigation menu, also highlighting the current active
> section (though CSS, no JS please).

I never quite managed to do that ... but it should definitely be doable.

/v

Re: [O] Org as a static site generator

[David Engster]

Vincent Beffara writes:
> I am using o-blog for that, it is pretty great. 

Thanks, that looks pretty nice. I'll take a look.

>> Thing of a typical HTML5 template having a , , ,
>> and . I'd like Org to include the different exported files into
>> the  section, and the rest to remain the same. The  would
>> contain a global navigation menu, also highlighting the current active
>> section (though CSS, no JS please).
>
> I never quite managed to do that ... but it should definitely be doable.

It's really simple to do. You just have to include some 'id' in the
 which indicates to which section it belongs to.

I've also just found this, which uses Org only as a markup tool and
Jekyll to generate the site:

http://orgmode.org/worg/org-tutorials/org-jekyll.html

But doing everything in Org is tempting, of course. And then just serve
that stuff with ElNode. :-)

-David

Re: [O] [BUG] [ODT] Subtree export gives wrong footnote style

[Christian Moe]

Hi, Nicolas,

Apologies, it looks like my installation is to blame, and that the part
of the patch that inserted the new style definitions was never applied
to OrgOdtStyles.xml. My org-odt-styles-dir becomes
"/usr/share/emacs/etc/org/styles/", not "etc/styles/". I assume the
latter would be the correct setup.

Yours,
Christian

Nicolas Goaziou writes:
> Judging by the output (i.e. contents.xml), styles are applied:
>
>   “I see that it is long”, 
> said Alice, “but how can a tail be sad?”
>   
>
>   Centered text here.
>   

> The question is: why aren't these styles effectively applied on the
> output. It may be related to their definition, which can be incorrect.

Re: [O] Org as a static site generator

[Vincent Beffara]

> > > Thing of a typical HTML5 template having a , , ,
> > > and . I'd like Org to include the different exported files into
> > > the  section, and the rest to remain the same. The  would
> > > contain a global navigation menu, also highlighting the current active
> > > section (though CSS, no JS please).
> > 
> > I never quite managed to do that ... but it should definitely be doable.
> 
> It's really simple to do. You just have to include some 'id' in the
>  which indicates to which section it belongs to.

Yes, I mean, I know which html you need for that, simply within o-blog you need 
to manage between relative paths, absolute paths, canonical paths and so on in 
the template, to match the right section,  - mainly it should be a matter of 
let-ing the right variable to the right value at the right point in the 
template and catching it when generating the toc, but I never took the time to 
get it right ...
> I've also just found this, which uses Org only as a markup tool and
> Jekyll to generate the site:
> 
> http://orgmode.org/worg/org-tutorials/org-jekyll.html
I had a look at the too, but it felt just a little bit too convoluted compared 
to managing everything from Org. Besides, it seems to lose fontification of 
code snippets and the like?

/v

[O] css link colors for Worg are difficult to spot

[John Hendy]

I find the links difficult to spot in Worg sometimes, especially
depending on monitor angle and current brightness setting. Is this an
issue for anyone else?

I fiddled around in /style/worg.css a bit and didn't land on anything
too great. I'm wondering if anyone with a design background might have
suggestions for link colors? I guess if no one else is affected by
this... I'll just deal with it and mine sweep wildly with my mouse
when I think a link should be in there somewhere :)



John

Re: [O] phone links...

[Robert Goldman]

On 3/29/13 Mar 29 -6:23 PM, Robert Goldman wrote:
> Since I keep my todo tasks in my org files, and some of them involve
> phone calls, I made a rudimentary handler for "phone:" links that I
> would like to contribute.  It features a link declaration (in
> org-phone.el) and an ancillary script (currently only working on Mac OS
> X, but should be translatable to other platforms) that can be used to
> place skype calls to the phone numbers.
> 
> One thing it does not do is support interactive entry of phone numbers.

Looks like the Right Thing here is to add a definition for an
org-phone-complete-link function.  I didn't read the manual carefully
enough

I'll see if I can whip something up, perhaps something that would use a
contacts database.

cheers,
r

Re: [O] Item task_id not being used in taskjuggler export

[Nicolas Goaziou]

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 2001
From: Nicolas Goaziou 
Date: Mon, 1 Apr 2013 16:08:37 +0200
Subject: [PATCH] ox-taskjuggler: Use task_id property when specified

* contrib/lisp/ox-taskjuggler.el (org-taskjuggler--build-unique-id):
  Use specified id (TASK_ID property) when possible.
---
 contrib/lisp/ox-taskjuggler.el | 23 +--
 1 file changed, 13 insertions(+), 10 deletions(-)

diff --git a/contrib/lisp/ox-taskjuggler.el b/contrib/lisp/ox-taskjuggler.el
index cdc9195..5b2e5cc 100644
--- a/contrib/lisp/ox-taskjuggler.el
+++ b/contrib/lisp/ox-taskjuggler.el
@@ -411,16 +411,19 @@ resource.  Its id is derived from its name and made unique
 against UNIQUE-IDS.  If the (downcased) first token of the
 headline is not unique try to add more (downcased) tokens of the
 headline or finally add more underscore characters (\"_\")."
-  (let* ((parts (org-split-string (org-element-property :raw-value item)))
-	 (id (org-taskjuggler--clean-id (downcase (pop parts)
-;; Try to add more parts of the headline to make it unique.
-(while (and (car parts) (member id unique-ids))
-  (setq id (concat id "_"
-   (org-taskjuggler--clean-id (downcase (pop parts))
-;; If it's still not unique, add "_".
-(while (member id unique-ids)
-  (setq id (concat id "_")))
-id))
+  (let ((id (org-string-nw-p (org-element-property :TASK_ID item
+;; If an id is specified, use it, as long as it's unique.
+(if (not (member id unique-ids)) id
+  (let* ((parts (org-split-string (org-element-property :raw-value item)))
+	 (id (org-taskjuggler--clean-id (downcase (pop parts)
+	;; Try to add more parts of the headline to make it unique.
+	(while (and (car parts) (member id unique-ids))
+	  (setq id (concat id "_"
+			   (org-taskjuggler--clean-id (downcase (pop parts))
+	;; If it's still not unique, add "_".
+	(while (member id unique-ids)
+	  (setq id (concat id "_")))
+	id
 
 (defun org-taskjuggler--clean-id (id)
   "Clean and return ID to make it acceptable for TaskJuggler.
-- 
1.8.2

Re: [O] [PATCH] Fix several byte-compile warnings in org-contrib files

[Nicolas Goaziou]

Hello,

Thanks for your patch. Here are a few comments.

Aaron Ecay  writes:

> +(require 'cl-lib)

This is not an option since Org has to support Emacsen older than 24.3.

> -  (add (remove-if (lambda (author) (string-match "others" author))
> -   (remove-duplicates (apply #'append (col :authors))
> +  (add (cl-remove-if (lambda (author) (string-match "others" author))
> +   (cl-remove-duplicates (apply #'append (col :authors))
>:test #'string=)))

Here, we can use `org-remove-if' and `org-uniquify'.


Regards,

-- 
Nicolas Goaziou

Re: [O] Item task_id not being used in taskjuggler export

[John Hendy]

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 response! It fixes the naming issue. My tasks now
indeed keep the task_id that I assign.

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:

#+begin_src org
* Project  :taskjuggler_project:

** Milestones  :M:
*** Task
:PROPERTIES:
:task_id:   M2
:depends:  ??? what goes here to depend on T.T8 ???
:END:

** Technical  :T:
   :PROPERTIES:
   :task_id:  T
   :END:
*** Task
:PROPERTIES:
:task_id:  T8
:depends:  T6 T7
:duration: 1d
:END:

#+end_src

The TJ syntax would be !!T.T8 to depend on T8 from "outside" of the
Technical bucket. At present, the exporter isn't picking this up and
there's no depends attribute with the exported headline (tried T8,
T.T8, and !!T.T8).



Thanks,
John

>
> Regards,
>
> --
> Nicolas Goaziou

Re: [O] [PATCH] Add 'inline-only option to org-export-babel-evaluate

[Aaron Ecay]

Hi Nicolas,

2013ko apirilak 1an, Nicolas Goaziou-ek idatzi zuen:
> 
> This sentence is wrong. Look, for example at
> `org-latex-inline-src-block'. The exporter doesn't delete anything,
> Babel does.

You’re right – I meant (and should have said) “the process of exporting”
more broadly, not the exporter in particular.

Sorry,

-- 
Aaron Ecay

Re: [O] Item task_id not being used in taskjuggler export

[Nicolas Goaziou]

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:
> :task_id:   M2
> :depends:  ??? what goes here to depend on T.T8 ???

It should be :depends: T8

Thank you for the feedback.


Regards,

-- 
Nicolas Goaziou

Re: [O] [BUG] [ODT] Subtree export gives wrong footnote style

[Nicolas Goaziou]

Christian Moe  writes:

> Apologies, it looks like my installation is to blame, and that the part
> of the patch that inserted the new style definitions was never applied
> to OrgOdtStyles.xml. My org-odt-styles-dir becomes
> "/usr/share/emacs/etc/org/styles/", not "etc/styles/". I assume the
> latter would be the correct setup.

Indeed. Try using

  #+odt_styles_file: "/path/to/etc/styles/OrgOdtStyles.xml"

in your buffer.  The styles should be applied to the buffer.

We could also make use of OrgFootnoteVerse and OrgFootnoteCode styles,
but I'm not sure about their definition.

For now, I think the patch is correct to apply. What do you think?


Regards,

-- 
Nicolas Goaziou

Re: [O] [PATCH 0/3] synctex support for pdf export

[Aaron Ecay]

Hi Nicolas,

2013ko apirilak 1an, Nicolas Goaziou-ek idatzi zuen:
> 
> Async export works out of-the-box (though not optimized). There's no
> special environment to set up.

For me, when I tried it the async emacs process died because it could
not find an external elisp library that I load from my init.el.  I
thought the problem was just a matter of me setting load-path
incorrectly or something, and never looked into it, since having async
export was not very important to me at the time (it just seemed like a
cool feature to try).

Now that this has come up, I have looked at it more.  It appears that
the /usr/share/emacs/site-lisp directory is not added to load-path in
the async export process.  I guess that it should be, since users’
init.el files could rely on libraries that are found there.

> 
> As you notice, there are many limitations and I agree some of them will
> be tedious to overcome. It also breaks asynchronous export.
> 
> Moreover, modifying both parser and core export framework for an
> optional feature within a single back-end family is not right, IMO.

I agree that this is suboptimal, yes.

> 
> While I acknowledge the investment put into this patch, I won't accept
> it in its current form. I might consider it if it only modifies
> ox-latex.el,

This will make the problem very difficult, if not impossible.  Generally
speaking, the buffer that the export functions see bears only a loose
relationship to the original buffer, since babel blocks, #+include
directives, etc. have changed the text.  I have tried to think of ways
to get around this fact, since working with the synctex file requires
knowing the original line number.  This is the best I could do.

My next idea is to use #+name properties on src blocks, tables, etc. to
try to line up the two buffers (:ID: properties could also be used, if
present).  However, this would be a pain, and I doubt it would work well
enough to justify itself.

Do you have any ideas about how this might be overcome?  What is needed
is to know, for any line in the exported output, which line of the org
file it corresponds to (within some small margin of error).

Thanks,

-- 
Aaron Ecay

Re: [O] Item task_id not being used in taskjuggler export

[John Hendy]

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 in master. Could you confirm it?
>
>> *** Task
>> :PROPERTIES:
>> :task_id:   M2
>> :depends:  ??? what goes here to depend on T.T8 ???
>
> It should be :depends: T8
>
> Thank you for the feedback.
>

That *would* work, but ox-taskjuggler has to correct for the fact that
T8 does not live in M2's bucket (M). Using T8 gives me this:

#+begin_src TJ
  task M2 "Task" {
depends !T8
milestone
  }
#+end_src

But that gives a compilation error becaust tj3 is looking for task
M.T8 when it should be T.T8.

#+begin_src terminal

$ tj3 test.tjp

Reading file test.tjp[  Done  ]
test.tjp:11: Error in scenario plan: Task M.M2 has unknown depends M.T8%===   ]

#+end_src

Perhaps this analogy would help. I've just created two directories and
two files. Here's the output of =tree= at the command line:

|-- M
|   |-- M1
|   `-- M2
|-- T
|   |-- T1
|   `-- T2

I want to link M1 to T1. The current behavior is trying to do so with
./T1, which doesn't work since M/T1 doesn't exist. I have to do
../T/T1.

This is how TJ works, which is why it can't resolve T8 by itself,
unless you correct for the proper relative path with respect to the
current parent. Relative directory path periods are akin to TJ's =!=
syntax.

- ./file -> !task_id
- ../file -> !!task_id
- ../dir/file -> !!task_id (dir).task_id (file)


Best regards,
John

>
> Regards,
>
> --
> Nicolas Goaziou

[O] babel results handling (was: Process hlines in imported tables)

[Rick Frankel]

On Sun, Mar 31, 2013 at 07:37:38AM -0600, Eric Schulte wrote:
> It is certainly true that Emacs Lisp is treated differently than all
> other languages.  There are also significant differences between
> languages, e.g., session evaluation doesn't make sense for some
> languages, and for other languages session evaluation is the only type
> of evaluation that does make sense.
> 
> In addition to that, with over 40 supported languages [1], There
> undoubtedly are cases where we are doing a bad job of ensuring
> inter-languages consistency.  If you can find concise examples which use
> demonstrate significant inconsistencies between languages, then we
> should be able to resolve those on a case by case basis.  In general I
> think ob-sh is probably the most widely used code block language, and
> can be treated as the gold standard against which other languages should
> be compared.

`sh' is probably not the best choice as a "gold standard" due to the
fact that it only supports STDOUT ("output" and not "value").

Many of the languages are obviously not general purpose, or do not
support (like shell), wrapped values (only STDOUT), or don't generate
text, so consistency does not matter (e.g., css, sass, sql, sqlite,
plantuml, dot).

Regardless, the attached org file is a first step an comparing the
result processing of some languages (specifically, sh, emacs-lisp,
perl and ruby), which, I think, covers a good portion of the babel use
of general purpose languages.

The upshot, is that perl value results match shell value/output
results and emacs-lisp, python and ruby all return about the same
results (elisp returns the quote characters from a verbatim string).

I still think that the scalar pipe-delimited processing from shell and
perl is wrong in that pipe-delimited data ends up w/ an extra column
if each line starts w/ a pipe, but not if the pipe is used like a
csv separator (between columns but not at the beginning or end of the
line).

Also, looking at the manual
(http://orgmode.org/manual/results.html#results) vs. the code, are
there are actually four classes of :results arguments with type broken
into type and format?

 - Type :: (file list vector table scalar verbatim)
 - Format :: (raw html latex org code pp drawer)

rick
* Value results procesing

The list of valid =:result= arguments
#+BEGIN_SRC elisp :results list
(cdr (assoc 'results org-babel-common-header-args-w-values))
#+END_SRC
#+results:
- (file list vector table scalar verbatim)
- (raw html latex org code pp drawer)
- (replace silent none append prepend)
- (output value)

You can add languages to this list to test them as well.
The genrator assumes that a double quoted string, with the escapes
=\n= and =\t= are valid in the language and that no statement
terminator is required. The "method" is the statement required for
the value to be returned to the wrapper code. (E.g., none for =perl=
and =ruby=, =sh= does not actually return values so needs an =echo=.)

#+NAME: languages
| language | method | array  |
|--++|
| sh   | echo   ||
| perl || [[qw[h1 h2]],[qw[r1 r2]]]  |
| ruby || [%w[h1 h2],%w[r1 r2]]  |
| elisp|| '((h1 h2) (r1 r2)) |
| python   | return | [["h1", "h2"],["r1","r2"]] |

** Generate test code :noexport:
#+NAME: block
#+BEGIN_SRC elisp :eval never
  (defun block (lang body function handler type)
(format
 " %s body, :results value %s %s
  ,#+BEGIN_SRC %s :results value %s %s :wrap example
%s %s
  ,#+END_SRC\n"
 (cond 
  ((not (not (string-match-p "^\"|" body))) "pipe delimited")
  ((not (not (string-match-p "^\"" body))) "tab delimited")
  (t "array"))
 handler type
 lang handler type function body))
#+END_SRC

Run this block to generate the test code. You can then execute the
test code by running =org-babel-execute-subtree= on [[*All%20Tests][All 
Tests]]. The
file exports resonably nicely to either HTML or LaTeX.

#+HEADER: :var languages=languages
#+HEADER: :var types='("" "table" "scalar" "verbatim")
#+HEADER: :var formatting='("" "raw")
#+HEADER: :var scalar="\"|h1|h2|\\n|-\\n|r1|r2|\""
#+HEADER: :var tab-delim="\"h1\\th2\\t\\nr1\\tr2\""
#+BEGIN_SRC elisp :results raw :noweb yes   
  (require 'ob-perl)
  (require 'ob-sh)
  (require 'ob-python)
  <>
  (save-excursion
(condition-case nil
(progn
  (goto-char (org-find-entry-with-id "ALL-TESTS"))
  (org-cut-subtree))
  (error t)))
  (concat
   "* All Tests\n"
   ":PROPERTIES:\n"
   ":ID:  ALL-TESTS\n"
   ":END:\n"
   (mapconcat
(lambda (lang)
  (format 
   "** %s\n%s" (car lang)
   (mapconcat
(lambda (formatter)
  (format "*** Result format: %s\n%s" 
  (if (string= formatter "") "default" formatter)
  (mapconcat 
   (lambda (type)
  

Re: [O] Item task_id not being used in taskjuggler export

[Nicolas Goaziou]

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 formatting. It should now be
>> fixed in master. Could you confirm it?
>>
>>> *** Task
>>> :PROPERTIES:
>>> :task_id:   M2
>>> :depends:  ??? what goes here to depend on T.T8 ???
>>
>> It should be :depends: T8
>>
>> Thank you for the feedback.
>>
>
> That *would* work, but ox-taskjuggler has to correct for the fact that
> T8 does not live in M2's bucket (M). Using T8 gives me this:
>
>
> #+begin_src TJ
>   task M2 "Task" {
> depends !T8
> milestone
>   }
> #+end_src

I cannot reproduce it. With:

* Project  :taskjuggler_project:

  ** 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 get:

  task project "Project" {
purge allocate
allocate nicolas
task milestones "Milestones" {
  task M2 "Task" {
depends !!T.T8
milestone
  }
}
task T "Technical" {
  task T8 "Task" {
duration 1d
  }
}
  }

which looks correct. Did you reload Org properly after update?


Regards,

-- 
Nicolas Goaziou

Re: [O] Item task_id not being used in taskjuggler export

[John Hendy]

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 correctly:
>>>
>>> There was indeed a bug in the dependencies formatting. It should now be
>>> fixed in master. Could you confirm it?
>>>
 *** Task
 :PROPERTIES:
 :task_id:   M2
 :depends:  ??? what goes here to depend on T.T8 ???
>>>
>>> It should be :depends: T8
>>>
>>> Thank you for the feedback.
>>>
>>
>> That *would* work, but ox-taskjuggler has to correct for the fact that
>> T8 does not live in M2's bucket (M). Using T8 gives me this:
>>
>>
>> #+begin_src TJ
>>   task M2 "Task" {
>> depends !T8
>> milestone
>>   }
>> #+end_src
>
> I cannot reproduce it. With:
>
> * Project  :taskjuggler_project:
>
>   ** 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 get:
>
>   task project "Project" {
> purge allocate
> allocate nicolas
> task milestones "Milestones" {
>   task M2 "Task" {
> depends !!T.T8
> milestone
>   }
> }
> task T "Technical" {
>   task T8 "Task" {
> duration 1d
>   }
> }
>   }
>
> which looks correct. Did you reload Org properly after update?

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

What perplexes me is that the id's mostly work (showing that the patch
definitely changed from the master branch behavior), but not the same
as you. With no task_id for Milestones, I'm getting:

task nil "Milestones" {

and you're getting

task milestones "Milestones" {

I'm also not getting the resolving of non-sibling depends attributes
(getting just !T8 instead of !!T.T8).

Did I not apply the patch or rebuild org properly? I'm pretty bad with
git, and it surprises me that `git status` shows that ox-taskjuggler
is modified when I switch back to master. I would have expected that
my master branch would be oblivious to the changes I made on the
tj-test branch (with `git branch tj-test && git checkout tj-test`).


Thanks,
John

>
>
> Regards,
>
> --
> Nicolas Goaziou

Re: [O] Item task_id not being used in taskjuggler export

[Nicolas Goaziou]

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. You should update
Org, reload it, and try again.


Regards,

-- 
Nicolas Goaziou

[O] New logo

[Bastien]

Hi all,

I've been trying hard to enhance the logo for the release of 8.0
and I gather that my attempts failed so far.  So instead of trying
to change the colors and the shape, I suddenly realized we could
simply find... a *better* animal.

What is the most appropriate symbol of why we all use Org-mode?

Yes, procrastination.  Fiddling with Emacs instead of achieving
the work we need to achieve.  Trying to convince ourselves that
this tiny Org feature will make us more proficient at our jobs,
instead of simply working.

I asked many Org friends during the last few weeks, and we all
agreed that an ostrich might be a good candidate.

So here it is -- I just updated the website accordingly:

  http://orgmode.org

I did spent a lot of time and energy on deciding this, and this
is not only me, but also many Org users I've asked, so please do
not discuss this change.

Hope you'll get used to it!

Best,

-- 
 Bastien

Re: [O] New logo

[Suvayu Ali]

On Mon, Apr 01, 2013 at 07:20:13PM +0200, Bastien wrote:
> 
> I asked many Org friends during the last few weeks, and we all
> agreed that an ostrich might be a good candidate.
> 
> So here it is -- I just updated the website accordingly:
> 
>   http://orgmode.org
> 
> I did spent a lot of time and energy on deciding this, and this
> is not only me, but also many Org users I've asked, so please do
> not discuss this change.

When I read the email, I thought "No! I want the unicorn!".  But then I
saw the ostrich, and now I don't know anymore.  I think the ostrich is
absolutely hilarious.

-- 
Suvayu

Open source is the future. It sets us free.

Re: [O] New logo

[Thorsten Jolitz]

Bastien  writes:

Amazing design skills ;)
and perfect timing for the announcement ...

-- 
cheers,
Thorsten

Re: [O] New logo

[Brian van den Broek]

On 1 April 2013 13:20, Bastien  wrote:
> Hi all,
>
> I've been trying hard to enhance the logo for the release of 8.0
> and I gather that my attempts failed so far.  So instead of trying
> to change the colors and the shape, I suddenly realized we could
> simply find... a *better* animal.
>
> What is the most appropriate symbol of why we all use Org-mode?
>
> Yes, procrastination.  Fiddling with Emacs instead of achieving
> the work we need to achieve.  Trying to convince ourselves that
> this tiny Org feature will make us more proficient at our jobs,
> instead of simply working.
>
> I asked many Org friends during the last few weeks, and we all
> agreed that an ostrich might be a good candidate.
>
> So here it is -- I just updated the website accordingly:
>
>   http://orgmode.org
>
> I did spent a lot of time and energy on deciding this, and this
> is not only me, but also many Org users I've asked, so please do
> not discuss this change.
>
> Hope you'll get used to it!
>
> Best,
>
> --
>  Bastien


Oh, +1. No, strike that. +4

Best,

Brian vdB

Re: [O] New logo

[Evan Misshula]

> I did spent a lot of time and energy on deciding this, and this
> is not only me, but also many Org users I've asked, so please do
> not discuss this change.

Seems like an April fools joke.  Of course we will discuss. :-P


On Mon, Apr 1, 2013 at 2:16 PM, Brian van den Broek <
brian.van.den.br...@gmail.com> wrote:

> On 1 April 2013 13:20, Bastien  wrote:
> > Hi all,
> >
> > I've been trying hard to enhance the logo for the release of 8.0
> > and I gather that my attempts failed so far.  So instead of trying
> > to change the colors and the shape, I suddenly realized we could
> > simply find... a *better* animal.
> >
> > What is the most appropriate symbol of why we all use Org-mode?
> >
> > Yes, procrastination.  Fiddling with Emacs instead of achieving
> > the work we need to achieve.  Trying to convince ourselves that
> > this tiny Org feature will make us more proficient at our jobs,
> > instead of simply working.
> >
> > I asked many Org friends during the last few weeks, and we all
> > agreed that an ostrich might be a good candidate.
> >
> > So here it is -- I just updated the website accordingly:
> >
> >   http://orgmode.org
> >
> > I did spent a lot of time and energy on deciding this, and this
> > is not only me, but also many Org users I've asked, so please do
> > not discuss this change.
> >
> > Hope you'll get used to it!
> >
> > Best,
> >
> > --
> >  Bastien
>
>
> Oh, +1. No, strike that. +4
>
> Best,
>
> Brian vdB
>
>


-- 
Evan Misshula
Doctoral Student (Criminal Justice)
CUNY John Jay
"Let us reform our schools, and we shall find little reform needed in our
prisons."
   John Ruskin, Unto This Last, essay 2 (1862)
   English critic, essayist, & reformer (1819 - 1900)

"Instruction does much, but encouragement does everything." Johann Wolfgang
Von Goethe
www.snrg-nyc.org

Re: [O] New logo

[Brian van den Broek]

On 1 Apr 2013 14:23, "Evan Misshula"  wrote:
>
> > I did spent a lot of time and energy on deciding this, and this
> > is not only me, but also many Org users I've asked, so please do
> > not discuss this change.
>
> Seems like an April fools joke.  Of course we will discuss. :-P
>
>
> On Mon, Apr 1, 2013 at 2:16 PM, Brian van den Broek <
brian.van.den.br...@gmail.com> wrote:



>> Oh, +1. No, strike that. +4
>>
>> Best,
>>
>> Brian vdB

That's not in keeping with the spirit of the thing. Knowing allusions (as
above) are fine, but overtly pointing it? That's not cricket!

Brian vdB

Re: [O] [BUG] [ODT] Subtree export gives wrong footnote style

[Christian Moe]

Hi again,

Now that I've finally pointed to the patched file, the patch seems to
work perfectly.

> We could also make use of OrgFootnoteVerse and OrgFootnoteCode styles,
> but I'm not sure about their definition.

It doesn't matter all that much, I think -- in any case the style
definition is entirely customizable, and the rare user who wants to use
them will probably want to tweak the style anyway. As long as they
inherit from Footnote and don't look really weird, it should be OK. 

Both could be indented like OrgFootnoteQuotation, the O.F.Code should
probably have a fixed-width font, and if you wanted to make the
distinction between O.F.Verse and O.F.Quotation visually clearer, I
guess verse could be italicised. (No need to copy the OrgVerse style...)

> For now, I think the patch is correct to apply. What do you think?

Absolutely, it fixes a bug in footnote styling, and adds useful styling
of quotes within footnotes.

Yours,
Christian

Re: [O] New logo

[Evan Misshula]

Apologies for any breech of protocol.  EM


On Mon, Apr 1, 2013 at 2:28 PM, Brian van den Broek <
brian.van.den.br...@gmail.com> wrote:

>
> On 1 Apr 2013 14:23, "Evan Misshula"  wrote:
> >
> > > I did spent a lot of time and energy on deciding this, and this
> > > is not only me, but also many Org users I've asked, so please do
> > > not discuss this change.
> >
> > Seems like an April fools joke.  Of course we will discuss. :-P
> >
> >
> > On Mon, Apr 1, 2013 at 2:16 PM, Brian van den Broek <
> brian.van.den.br...@gmail.com> wrote:
>
> 
>
> >> Oh, +1. No, strike that. +4
> >>
> >> Best,
> >>
> >> Brian vdB
>
> That's not in keeping with the spirit of the thing. Knowing allusions (as
> above) are fine, but overtly pointing it? That's not cricket!
>
> Brian vdB
>



-- 
Evan Misshula
Doctoral Student (Criminal Justice)
CUNY John Jay
"Let us reform our schools, and we shall find little reform needed in our
prisons."
   John Ruskin, Unto This Last, essay 2 (1862)
   English critic, essayist, & reformer (1819 - 1900)

"Instruction does much, but encouragement does everything." Johann Wolfgang
Von Goethe
www.snrg-nyc.org

[O] ostrich mascott but with reading glasses (was: Re: New logo)

[Gregor Zattler]

Hi Bastien,
* Bastien  [01. Apr. 2013]:

[... ostrich as the new org-mode logo ...]
 
> I did spent a lot of time and energy on deciding this, and this
> is not only me, but also many Org users I've asked, so please do
> not discuss this change.

I'm fine with Bastiens choice of an ostrich as org-mode `logo' --
in hindsight it seems really obvious.  Most probably it was the
unicorn which hindered org-modes mass acceptance.

But I think it's not o.k. to force a `logo' onto the community:

First we shouldn't use the word `logo' with it's evil
connotations of commerce.  Let us use the word `mascot' instead,
since it's a living being.

Second I think to really demonstrate org-modes procrastinating
power the ostrich should wear reading glasses and read the
org-mode manual.  This would have the added benefit that we could
dismiss noobs and newbies with an "do as the ostrich does!"
instead of this rather vulgar `RTFM' thing.

The more conservative org-mode users may argue -- and in sharp
contrast to our benevolent dictator Bastien I encourage everyone
to argue over everything -- that ostrichs typically are portrayed
with their head in the sand.  Being in harmonic mode at the
moment I would propose as a compromise that the ostrich wears
reading glasses while stuck with the head in the sand.

Ciao, Gregor
-- 
 -... --- .-. . -.. ..--.. ...-.-

Re: [O] New logo

[Allen S. Rout]

On 04/01/2013 02:28 PM, Brian van den Broek wrote:

> 
> That's not in keeping with the spirit of the thing. Knowing allusions (as
> above) are fine, but overtly pointing it? That's not cricket!


Mmm.  Maybe a _REALLY_ big turkey on a platter?

- Allen S. Rout

Re: [O] New logo

[Allen S. Rout]

On 04/01/2013 02:35 PM, Evan Misshula wrote:
> Apologies for any breech of protocol.  EM
> 

Ew.

- Allen S. Rout

Re: [O] New logo

[Christian Moe]

+1! :)

It's a great logo for a great PTO[1] tool.

Yours,
Christian

[1] PTO = Putting Things Off

Bastien writes:

> Hi all,
>
> I've been trying hard to enhance the logo for the release of 8.0
> and I gather that my attempts failed so far.  So instead of trying
> to change the colors and the shape, I suddenly realized we could
> simply find... a *better* animal.
>
> What is the most appropriate symbol of why we all use Org-mode?
>
> Yes, procrastination.  Fiddling with Emacs instead of achieving
> the work we need to achieve.  Trying to convince ourselves that
> this tiny Org feature will make us more proficient at our jobs,
> instead of simply working.
>
> I asked many Org friends during the last few weeks, and we all
> agreed that an ostrich might be a good candidate.
>
> So here it is -- I just updated the website accordingly:
>
>   http://orgmode.org
>
> I did spent a lot of time and energy on deciding this, and this
> is not only me, but also many Org users I've asked, so please do
> not discuss this change.
>
> Hope you'll get used to it!
>
> Best,

Re: [O] Org as a static site generator

[Ian Barton]

On 01/04/13 13:08, Vincent Beffara wrote:


Yes, I mean, I know which html you need for that, simply within o-blog you need 
to manage between relative paths, absolute paths, canonical paths and so on in 
the template, to match the right section,  - mainly it should be a matter of 
let-ing the right variable to the right value at the right point in the 
template and catching it when generating the toc, but I never took the time to 
get it right ...

I've also just found this, which uses Org only as a markup tool and
Jekyll to generate the site:

http://orgmode.org/worg/org-tutorials/org-jekyll.html

I had a look at the too, but it felt just a little bit too convoluted compared 
to managing everything from Org. Besides, it seems to lose fontification of 
code snippets and the like?

/v

As the original author of that page, I agree that using Jekyll is 
convoluted, but it gives you much more control. However I now use 
Pelican: https://pelican.readthedocs.org/en/3.1.1/


There are a few reasons for this. Pelican is written in Python, which I 
find easier to hack on. It is more flexible than Jekyll, which I found 
hard to get to work the way I wanted with categories and tags.


I wrote a yaml importer for Pelican so I could use my old jekyll posts. 
However, Pelican understands Markdown, which I think the new exporter 
supports.


So my work flow now is Emacs-> export as html -> run Jekyll

Ian.

[O] Org-mode as a metalanguage: calling SQL "functions"

[Gary Oberbrunner]

It seems like you can define "procedures" in org-mode and call them from
elsewhere, with args.
But I'm not sure how well-defined that process is; the documentation is not
completely perfect yet I think.  Here's one thing I'm trying that seems not
to work.

I define a "procedure" as a named ref called recorddate with two args, ver
and order.  The idea is I could later call that with different values of
those args.

#+NAME: recorddate(order="desc")
#+BEGIN_SRC sql :exports none :colnames no :results scalar
select Event.CreatedAt from Event join MachineInfo as MI on
Event.MachineInfoId=MI.Id
 where Event.CreatedAt is not NULL order by CreatedAt $order limit 1;
#+END_SRC sql

(BTW, I really like how $ vars are substituted into SQL.  Nice.)  But when
I try to call it like this:

 * earliest record is call_recorddate(ver="'.'", order="asc")
or like this:
 #+CALL: recorddate(ver="'.'", order="asc")

and I try to export as LaTeX (or anything), I get
 org-babel-ref-resolve: Reference 'recorddate' not found in this buffer

Is this supposed to work?

-- 
Gary

Re: [O] ostrich mascott but with reading glasses (was: Re: New logo)

[Brian van den Broek]

On 1 Apr 2013 14:36, "Gregor Zattler"  wrote:



> The more conservative org-mode users may argue -- and in sharp
> contrast to our benevolent dictator Bastien I encourage everyone
> to argue over everything -- that ostrichs typically are portrayed
> with their head in the sand.  Being in harmonic mode at the
> moment I would propose as a compromise that the ostrich wears
> reading glasses while stuck with the head in the sand.

It is a non-problem. After all, glass is made of sand!

Best,

Brian vdB

Re: [O] New logo

[Carsten Dominik]

On 1.4.2013, at 19:20, Bastien  wrote:

> Hi all,
> 
> I've been trying hard to enhance the logo for the release of 8.0
> and I gather that my attempts failed so far.  So instead of trying
> to change the colors and the shape, I suddenly realized we could
> simply find... a *better* animal.
> 
> What is the most appropriate symbol of why we all use Org-mode?
> 
> Yes, procrastination.  Fiddling with Emacs instead of achieving
> the work we need to achieve.  Trying to convince ourselves that
> this tiny Org feature will make us more proficient at our jobs,
> instead of simply working.
> 
> I asked many Org friends during the last few weeks, and we all
> agreed that an ostrich might be a good candidate.
> 
> So here it is -- I just updated the website accordingly:
> 
>  http://orgmode.org
> 
> I did spent a lot of time and energy on deciding this, and this
> is not only me, but also many Org users I've asked, so please do
> not discuss this change.
> 
> Hope you'll get used to it!


Wow, I've got to hand it to you.  After the recent color experiments - this one 
does not make me physically sick, and it is in fact a fine depiction of how I 
feel way too often.  Seems perfectly suited for an animated gif logo, too!

Great work!

- Carsten

Re: [O] Org-mode as a metalanguage: calling SQL "functions"

[Mike Gauland]

Gary Oberbrunner  oberbrunner.com> writes:
> Is this supposed to work?
> -- Gary

I'm not sure how it's /supposed/ to work, either, but this example works for a
sqlite database I've been playing with:

  #+NAME: artist
  #+BEGIN_SRC sqlite :db the_sound_A-Z.sql :var song_title=""
  select artist from playlist where title=="$song_title";
  #+END_SRC

  #+CALL: artist(song_title="Pressure")

  #+RESULTS: artist(song_title="Pressure")
  : Billy Joel

Note the need for double quotes around $song_title in the SRC block.

I'm using the latest from git, and emacs 23.2.1 on Debian.

Hope that helps.

Kind Regards,
Mike Gauland

Re: [O] colorg: Protocol [was: Re: Rudel - Real-Time collaborative editing of Org-Mode files]

[Torben Hoffmann]

Hi François,

I recently read an interesting article on Convergent and Commutative
Replicated Data Types (
http://hal.inria.fr/docs/00/55/55/88/PDF/techreport.pdf) which happened to
have a section called "Co-operative text editing" that seems spot on for
the problem you are trying to solved. They mention two existing solutions -
Logoot and Treedoc - that might be worth investigating...

I'm not saying that any of these will solve the problem, but by nature (and
my heavy schooling in Math) I am too lazy not to consider stealing a
solution instead of inventing my own! ;-)

Cheers,
__
 /orben


On Mon, Jan 14, 2013 at 3:38 PM, François Pinard wrote:

> Samuel Loury  writes:
>
> > But instead of creating your own protocol, have you thought about
> > extending an already existing one?
>
> Yes, of course.  My goal is getting some solution, not creating my own
> thing.  I only tried to look at the internals of Rudel and
> Etherpad-lite, and also to read some literature on the topic, starting
> with Wikipedia.  In all cases, I felt stupid and overwhelmed. :-)  This
> is not simple, as far as I can see.
>
> > I see that you have read negative comments about tools using the obby
> > protocol, but have you read about the protocol itself?
>
> Besides Rudel, no.
>
> > By recreating a new protocol, you might be facing the same issues in
> > synchronization that gooby faced at some time and spending useless
> > effort trying to fix it.
>
> While not being fully sure, I think I have some understanding of the
> problem, and the solution I have in head might have no issue.  Its
> optimization is going to be a bit hairy however, and there lies the
> danger for introducing errors.  My fix would then be to not optimize, so
> with at least an inefficient solution, the effort is not useless. :-).
>
> > As far as I can see, the only thing that appears to be missing in the
> > obby protocol is the possibility to move entries without deleting and
> > reinserting.  This makes sense since it is specific to outlined
> > documents.  Why not adding this feature to the obby protocol?
>
> Because of the bad press, which gave me the unverified impression that
> by adopting Obby, I would have to spouse its problems, and get to solve
> them.  I guess people much more brilliant than me already tried, and
> failed or abandoned, so I just have no chance of succeeding :-).
>
> It sounds important to me, for Org mode, to support some "Move Block"
> operation, which combines delete and reinsert the same contents as a
> single operation instead of two, as I suspect this is frequent when
> someone is reorganize an Org outline, and I would ideally like that
> people editing within a block which is being moved by someone else does
> barely notice s/he is being shuffled elsewhere.  This is an Org
> specialty, that is unlikely part of other protocols, and this
> consideration pushed me into attempting something.  Not that I currently
> have a "Move Block" operation in the protocol, but it should be easier
> to add to something that I well understand.
>
> > By the way, I tried this week end gobby server 0.4 and rudel client
> > (last git version) and it did not manage to connect to the gobby server
> > while a gobby client 0.4 succeeded. So sad...
>
> I also got quick failures in my tries, of many kinds.
>
> > [1] http://gobby.0x539.de/trac/wiki/AnnotatedObbySession
>
> Thanks for this one, which I did not see.  I'll take a closer look!
>
> > If the obby protocol or any other RTCE protocol does not fit your needs
> > causing the creation of a new protocol, I think it would be a good idea
> > to write why on your wiki page.
>
> I'm saving these messages and recycling their content on the Wiki.  I
> should get more documentation on the Wiki, but did not have much time
> since I started, Friday evening, as I rather wanted to push on the code
> to have by Sunday at least some skeleton that moves a bit.  And even
> then, I took the time to move some previous comments to the Wiki, and
> explain at least the current state of protocol.  Documenting early helps
> at avoiding design errors.
>
> > I can't wait to see RTCE of org document!
>
> Ista Zahn published a working solution on the Wiki, that one could use
> if in a hurry.  It is said to work well, see:
>
>https://github.com/pinard/ColOrg/wiki/emacsclient
>
> François
>



-- 
http://www.linkedin.com/in/torbenhoffmann

Re: [O] New logo

[Michael Gauland]

Bastien  altern.org> writes:
> 
> I asked many Org friends during the last few weeks, and we all
> agreed that an ostrich might be a good candidate.

I'm afraid this logo sends the wrong message. It should be showing the
non-org-users of the world with their heads in the sand.

Or maybe the logo should include the subterranean wonders of org the ostrich
(orgstrich?) is marveling at?

--Mike

Re: [O] Item task_id not being used in taskjuggler export & tj prefixing

[Buddy Butterfly]

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.

Also, you will likely only implement subsets of tj
properties.

For example, there are properties missing like

  :workinghours:

Lets look at an example. Suppose
we would prefix all taskjuggler properties with "tj_"
and org-mode would export tj_ properties as is.
People then would directly code the dependency
themself.

Your example would look like
(if directly replaced)

  ** Milestones  :M:
  *** Task
  :PROPERTIES:
  :tj_task_id: M2
  :tj_depends: !!T.T8
  :END:

  ** Technical  :T:
 :PROPERTIES:
 :tj_task_id:  T
 :END:
  *** Task
  :PROPERTIES:
  :tj_task_id:  T8
  :tj_duration: 1d
  :END:

Also, properties to the project tag should go into the
project task. With the functionality above, it would be easy to:

* Project  :taskjuggler_project:
  :workinhours: mon - fri 08:00 - 17:00

Or give a flag:


  ** Technical  :T:
 :PROPERTIES:
 :tj_task_id:  T
 :END:
  *** Task
  :PROPERTIES:
  :tj_task_id:  T8
  :tj_duration: 1d
  :tj_flag: tech8flag
  :END:


I have some other points to discuss. Will create a separate thread for it.

Cheers,
Matt



Am 01.04.2013 18:57, schrieb John Hendy:
> 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 correctly:
 There was indeed a bug in the dependencies formatting. It should now be
 fixed in master. Could you confirm it?

> *** Task
> :PROPERTIES:
> :task_id:   M2
> :depends:  ??? what goes here to depend on T.T8 ???
 It should be :depends: T8

 Thank you for the feedback.

>>> That *would* work, but ox-taskjuggler has to correct for the fact that
>>> T8 does not live in M2's bucket (M). Using T8 gives me this:
>>>
>>>
>>> #+begin_src TJ
>>>   task M2 "Task" {
>>> depends !T8
>>> milestone
>>>   }
>>> #+end_src
>> I cannot reproduce it. With:
>>
>> * Project  :taskjuggler_project:
>>
>>   ** 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 get:
>>
>>   task project "Project" {
>> purge allocate
>> allocate nicolas
>> task milestones "Milestones" {
>>   task M2 "Task" {
>> depends !!T.T8
>> milestone
>>   }
>> }
>> task T "Technical" {
>>   task T8 "Task" {
>> duration 1d
>>   }
>> }
>>   }
>>
>> which looks correct. Did you reload Org properly after update?
> 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
>
> What perplexes me is that the id's mostly work (showing that the patch
> definitely changed from the master branch behavior), but not the same
> as you. With no task_id for Milestones, I'm getting:
>
> task nil "Milestones" {
>
> and you're getting
>
> task milestones "Milestones" {
>
> I'm also not getting the resolving of non-sibling depends attributes
> (getting just !T8 instead of !!T.T8).
>
> Did I not apply the patch or rebuild org properly? I'm pretty bad with
> git, and it surprises me that `git status` shows that ox-taskjuggler
> is modified when I switch back to master. I would have expected that
> my master branch would be oblivious to the changes I made on the
> tj-test branch (with `git branch tj-test && git checkout tj-test`).
>
>
> Thanks,
> John
>
>>
>> Regards,
>>
>>

Re: [O] Item task_id not being used in taskjuggler export & tj prefixing

[Buddy Butterfly]

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:
>   *** 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.
>
> Also, you will likely only implement subsets of tj
> properties.
>
> For example, there are properties missing like
>
>   :workinghours:
>
> Lets look at an example. Suppose
> we would prefix all taskjuggler properties with "tj_"
> and org-mode would export tj_ properties as is.
> People then would directly code the dependency
> themself.
>
> Your example would look like
> (if directly replaced)
>
>   ** Milestones  :M:
>   *** Task
>   :PROPERTIES:
>   :tj_task_id: M2
>   :tj_depends: !!T.T8
>   :END:
>
>   ** Technical  :T:
>  :PROPERTIES:
>  :tj_task_id:  T
>  :END:
>   *** Task
>   :PROPERTIES:
>   :tj_task_id:  T8
>   :tj_duration: 1d
>   :END:
>
> Also, properties to the project tag should go into the
> project task. With the functionality above, it would be easy to:
>
> * Project  :taskjuggler_project:
>   :tj_workinhours: mon - fri 08:00 - 17:00
>
> Or give a flag:
>
>
>   ** Technical  :T:
>  :PROPERTIES:
>  :tj_task_id:  T
>  :END:
>   *** Task
>   :PROPERTIES:
>   :tj_task_id:  T8
>   :tj_duration: 1d
>   :tj_flag: tech8flag
>   :END:
>
>
> I have some other points to discuss. Will create a separate thread for it.
>
> Cheers,
> Matt
>
>
>
> Am 01.04.2013 18:57, schrieb John Hendy:
>> 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 correctly:
> There was indeed a bug in the dependencies formatting. It should now be
> fixed in master. Could you confirm it?
>
>> *** Task
>> :PROPERTIES:
>> :task_id:   M2
>> :depends:  ??? what goes here to depend on T.T8 ???
> It should be :depends: T8
>
> Thank you for the feedback.
>
 That *would* work, but ox-taskjuggler has to correct for the fact that
 T8 does not live in M2's bucket (M). Using T8 gives me this:


 #+begin_src TJ
   task M2 "Task" {
 depends !T8
 milestone
   }
 #+end_src
>>> I cannot reproduce it. With:
>>>
>>> * Project  :taskjuggler_project:
>>>
>>>   ** 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 get:
>>>
>>>   task project "Project" {
>>> purge allocate
>>> allocate nicolas
>>> task milestones "Milestones" {
>>>   task M2 "Task" {
>>> depends !!T.T8
>>> milestone
>>>   }
>>> }
>>> task T "Technical" {
>>>   task T8 "Task" {
>>> duration 1d
>>>   }
>>> }
>>>   }
>>>
>>> which looks correct. Did you reload Org properly after update?
>> 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
>>
>> What perplexes me is that the id's mostly work (showing that the patch
>> definitely changed from the master branch behavior), but not the same
>> as you. With no task_id for Milestones, I'm getting:
>>
>> task nil "Milestones" {
>>
>> and you're getting
>>
>> task milestones "Milestones" {
>>
>> I'm also not getting the resolving of non-sibling depends attributes
>> (getting just !T8 instead of !!T.T8).
>>
>> Did I not apply the patch or rebuild org

Re: [O] Item task_id not being used in taskjuggler export & tj prefixing

[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

Re: [O] Item task_id not being used in taskjuggler export & tj prefixing

[Nicolas Goaziou]

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.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.

You can already do so. IDs only have to be unique within the task
siblings.

> 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.

You don't have to name parents either. You only need to name tasks that
will be used as a dependency.


Regards,

-- 
Nicolas Goaziou

Re: [O] [BUG] [ODT] Subtree export gives wrong footnote style

[Nicolas Goaziou]

Christian Moe  writes:

>> For now, I think the patch is correct to apply. What do you think?
>
> Absolutely, it fixes a bug in footnote styling, and adds useful styling
> of quotes within footnotes.

Patch applied.  Thank you.


Regards,

-- 
Nicolas Goaziou

Re: [O] New logo

[Rasmus]

Michael Gauland  writes:

> Bastien  altern.org> writes:
>> 
>> I asked many Org friends during the last few weeks, and we all
>> agreed that an ostrich might be a good candidate.

I have long been scared of that rather foul looking unicorn.  Great
job!  Next step is replacing the Gnu is Emacs Core!

–Rasmus

-- 
Hooray!

Re: [O] New logo

[Anthony Lander]

On 13-Apr-1, at 1:20 PM, Bastien wrote:

> Hi all,
> 
> I've been trying hard to enhance the logo for the release of 8.0
> and I gather that my attempts failed so far.  So instead of trying
> to change the colors and the shape, I suddenly realized we could
> simply find... a *better* animal.

Bastien, the ostrich is fantastic. Kudos!

  -Anthony

Re: [O] Org-mode as a metalanguage: calling SQL "functions"

[Eric Abrahamsen]

Gary Oberbrunner  writes:

> It seems like you can define "procedures" in org-mode and call them
> from elsewhere, with args.
> But I'm not sure how well-defined that process is; the documentation
> is not completely perfect yet I think. Here's one thing I'm trying
> that seems not to work.
>
> I define a "procedure" as a named ref called recorddate with two args,
> ver and order. The idea is I could later call that with different
> values of those args.
>
> #+NAME: recorddate(order="desc")
> #+BEGIN_SRC sql :exports none :colnames no :results scalar
> select Event.CreatedAt from Event join MachineInfo as MI on
> Event.MachineInfoId=MI.Id
> where Event.CreatedAt is not NULL order by CreatedAt $order limit 1;
> #+END_SRC sql
>
> (BTW, I really like how $ vars are substituted into SQL. Nice.) But
> when I try to call it like this:
>
> * earliest record is call_recorddate(ver="'.'", order="asc")
> or like this:
> #+CALL: recorddate(ver="'.'", order="asc")
>
> and I try to export as LaTeX (or anything), I get 
> org-babel-ref-resolve: Reference 'recorddate' not found in this buffer
>
> Is this supposed to work?

You're supposed to "load" named blocks before you can call them with
#+CALL, etc. I'm a little surprised that it doesn't automatically find
blocks defined in the same buffer, but calling C-c C-v i (ie
org-babel-lob-ingest) and loading the present file should make
"recorddate" available for calling.

E

Re: [O] Org-mode as a metalanguage: calling SQL "functions"

[Eric Abrahamsen]

Eric Schulte  writes:

> Eric Abrahamsen  writes:
>
>> Gary Oberbrunner  writes:
>>
>>> It seems like you can define "procedures" in org-mode and call them
>>> from elsewhere, with args.
>>> But I'm not sure how well-defined that process is; the documentation
>>> is not completely perfect yet I think. Here's one thing I'm trying
>>> that seems not to work.
>>>
>>> I define a "procedure" as a named ref called recorddate with two args,
>>> ver and order. The idea is I could later call that with different
>>> values of those args.
>>>
>>> #+NAME: recorddate(order="desc")
>>> #+BEGIN_SRC sql :exports none :colnames no :results scalar
>>> select Event.CreatedAt from Event join MachineInfo as MI on
>>> Event.MachineInfoId=MI.Id
>>> where Event.CreatedAt is not NULL order by CreatedAt $order limit 1;
>>> #+END_SRC sql
>>>
>>> (BTW, I really like how $ vars are substituted into SQL. Nice.) But
>>> when I try to call it like this:
>>>
>>> * earliest record is call_recorddate(ver="'.'", order="asc")
>>> or like this:
>>> #+CALL: recorddate(ver="'.'", order="asc")
>>>
>>> and I try to export as LaTeX (or anything), I get 
>>> org-babel-ref-resolve: Reference 'recorddate' not found in this buffer
>>>
>>> Is this supposed to work?
>>
>
> Yes, your example should work.  From the "Evaluating code blocks"
> section of the Org-mode manual.
>
> ,
> |It is also possible to evaluate named code blocks from anywhere in an
> | Org mode buffer or an Org mode table.  Live code blocks located in the
> | current Org mode buffer or in the "Library of Babel" (see *note Library
> | of Babel::) can be executed.  Named code blocks can be executed with a
> | separate '#+CALL:' line or inline within a block of text.
> `
>
> There is no need to load code blocks in the same buffer into the library
> of babel.

I think what he (and I, when I tried his version) ran into is that
without a ":var" attribute on the named code block, you get
the "not found" error.

Ie, simply declaring #+name: recorddate(order="desc") isn't enough to
let the block know to expect the var.

Presumably that *should* be an error, as the variable should be declared
before being used, but the actual error message is a little misleading.

Eric

> This example works for me evaluating code blocks in the same buffer
> using call lines.
>
> #+Title: Call Example
>
> #+name: example-block
> #+begin_src sh :var input=""
>   echo "input is $input"
> #+end_src
>
> Here's a simple call using a named argument.
> #+call: example-block(input="foo")
>
> #+RESULTS: example-block(input="foo")
> : input is foo
>
> It also works with a positional argument.
> #+call: example-block("bar")
>
> #+RESULTS: example-block("bar")
> : input is bar
>
> When I export this to e.g., html I get the following.
>
> Call Example
>
> Call Example
>
> echo "input is $input"
>
> Here's a simple call using a named argument. 
>
>
> input is foo
>
> It also works with a positional argument. 
>
>
> input is bar
>
> Date: 2013-04-01T19:39-0600
>
> Author: 
>
> Org version 7.9.3f with Emacs version 24
>
> Validate XHTML 1.0 
>
>
> The call lines are replaced with their results as part of the export
> process.
>
> If the above doesn't work for you, then I imagine something is wrong
> with your install.

Re: [O] Org-mode as a metalanguage: calling SQL "functions"

[Gary Oberbrunner]

Aha -- you have to use the :var syntax on the begin_src line, not the
params-in-parens syntax on the name line.  Your version works:

#+name: example-block
#+begin_src sh :var input=""
  echo "input is $input"
#+end_src

but this doesn't:

#+name: example-block(input="")
#+begin_src sh
  echo "input is $input"
#+end_src

The doc seems to say it should work the same, in
http://orgmode.org/manual/var.html (see "Alternate Argument Syntax").



On Mon, Apr 1, 2013 at 9:45 PM, Eric Schulte  wrote:

> Eric Abrahamsen  writes:
>
> > Gary Oberbrunner  writes:
> >
> >> It seems like you can define "procedures" in org-mode and call them
> >> from elsewhere, with args.
> >> But I'm not sure how well-defined that process is; the documentation
> >> is not completely perfect yet I think. Here's one thing I'm trying
> >> that seems not to work.
> >>
> >> I define a "procedure" as a named ref called recorddate with two args,
> >> ver and order. The idea is I could later call that with different
> >> values of those args.
> >>
> >> #+NAME: recorddate(order="desc")
> >> #+BEGIN_SRC sql :exports none :colnames no :results scalar
> >> select Event.CreatedAt from Event join MachineInfo as MI on
> >> Event.MachineInfoId=MI.Id
> >> where Event.CreatedAt is not NULL order by CreatedAt $order limit 1;
> >> #+END_SRC sql
> >>
> >> (BTW, I really like how $ vars are substituted into SQL. Nice.) But
> >> when I try to call it like this:
> >>
> >> * earliest record is call_recorddate(ver="'.'", order="asc")
> >> or like this:
> >> #+CALL: recorddate(ver="'.'", order="asc")
> >>
> >> and I try to export as LaTeX (or anything), I get
> >> org-babel-ref-resolve: Reference 'recorddate' not found in this buffer
> >>
> >> Is this supposed to work?
> >
>
> Yes, your example should work.  From the "Evaluating code blocks"
> section of the Org-mode manual.
>
> ,
> |It is also possible to evaluate named code blocks from anywhere in an
> | Org mode buffer or an Org mode table.  Live code blocks located in the
> | current Org mode buffer or in the "Library of Babel" (see *note Library
> | of Babel::) can be executed.  Named code blocks can be executed with a
> | separate '#+CALL:' line or inline within a block of text.
> `
>
> There is no need to load code blocks in the same buffer into the library
> of babel.
>
> This example works for me evaluating code blocks in the same buffer
> using call lines.
>
>
>
> When I export this to e.g., html I get the following.
>
>
> ** **
>   Call Example
>
> echo "input is $input"
>
>  Here's a simple call using a named argument.
>
> input is foo
>
>  It also works with a positional argument.
>
> input is bar
>
>  Date: 2013-04-01T19:39-0600
>
> Author:
>
> Org  version 7.9.3f with 
> Emacsversion 24
> Validate XHTML 1.0 
>
>
> The call lines are replaced with their results as part of the export
> process.
>
> If the above doesn't work for you, then I imagine something is wrong
> with your install.
>
> --
> Eric Schulte
> http://cs.unm.edu/~eschulte
>
>


-- 
Gary

[O] yanking a headline in folded state

[42 147]

Hello mailing list,

A source of slight irritation is killing a whole headline with C-k
(usually to move it to another buffer), and seeing it unfold every
single sub-headline after I yank it to its new position. This causes
tremendous chaos sometimes, especially if there are a number of nested
sub-headlines, and the killed headline itself needs to be adjusted to a
deeper / shallower level (depending on where I inserted it).

So in fewer words: how do I yank a headline in its folded state?

Much thanks,

42

Re: [O] New logo

[42 147]

> Or maybe the logo should include the subterranean wonders of org the
ostrich
> (orgstrich?) is marveling at?

Completely awesome suggestion. Please integrate.

The logo is indeed hilarious though.

Re: [O] Item task_id not being used in taskjuggler export & tj prefixing

[John Hendy]

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. 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.
>
> 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 the
lowest level of id (e.g. "T1" instead of "T.T1"), Org doesn't know how
to resolve them properly. Consider this  modified test file:

#+begin_src org

* Project  :taskjuggler_project:

** Milestones  :M:
*** M.M1
  :PROPERTIES:
  :task_id: M1
  :depends: T1
  :END:
*** M.T1
:PROPERTIES:
:task_id:  T1
:END:
** Technical  :T:
 :PROPERTIES:
 :task_id:  T
 :END:
*** T.T1
   :PROPERTIES:
   :task_id:  T1
   :END:

#+end_src

The resultant TJ export:

#+begin_src tj

task milestones "Milestones" {
  purge allocate
  allocate jwhendy
  task M1 "M.M1" {
depends !T1, !!T.T1
milestone
  }
  task T1 "M.T1" {
milestone
  }
}
task T "Technical" {
  task T1 "T.T1" {
milestone
  }
}

#+end_src

Task M1 ends up depending on both M.T1 (represented as !T1) /and/
T.T1. It won't fail since both T.T1 and M.T1 exist, but the user has
no way to set a depends option to target the specific T1 they wanted.
Setting =:depends: !!T.T1= ignores the :depends: property entirely.


Best regards,
John

>
>> 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.
>
> You don't have to name parents either. You only need to name tasks that
> will be used as a dependency.
>

True, which is nice. But we're torn between:
- Letting Org name the parent whatever it wants, but then having to
figure out the org-generated parent id so we can do =:depends:
parent.subtask=, or

- Specifically naming the parent to have control over the task_id, but
having to change it because we move it later (and then updating all
=:depends: parent.task_id= properties accordingly)

And in either case, there's still no way to depend on a specific
=parent.task_id= combination.


Best regards,
John

>
> Regards,
>
> --
> Nicolas Goaziou

Re: [O] Item task_id not being used in taskjuggler export

[John Hendy]

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 Emacs session
>
> Dismiss the patch. I pushed the changes into master. You should update
> Org, reload it, and try again.

Sorry -- I thought you were still describing the behavior of the patch
you sent. Posted in the other thread with the results, which are that:
- ID is correctly assigned now
- Depends resolve as long as there is only one global instance of that
specific task_id
- If you depend on a non-globally-unique task_id (e.g. there is an
M.T1 and also a T.T1, and you use =:depends: T1=), that task will end
up depending on both of them.


Best regards,
John

>
>
> Regards,
>
> --
> Nicolas Goaziou