Thanks to Christopher Witte for raising these issues
* lisp/babel/langs/ob-haskell.el (org-babel-expand-body:haskell):
replaced missing () wrapping, and now using correct variable
expansion
(org-babel-execute:haskell): now using
org-babel-haskell-initiate-session to start sessions
(org-babel-haskell-initiate-session): only starting sessions if none
exists, also added a .25 second wait on brand new sessions to allow
the Haskell interpreter to fire up
(org-babel-load-session:haskell): now optionally accepts processed
params to avoid over-execution of variable resolution
(org-babel-prep-session:haskell): now optionally accepts processed
params to avoid over-execution of variable resolution, also placing
the variable definitions directly in the session instead of loading
them from a separate file
* lisp/org-entities.el (org-entities): Restructure the list.
(org-entities-help): Turn the help output into a buffer
in Org-mode, so that it becomes easier to find a symbol
in the structure.
(org-entities-create-table): Deal with new structure.
Thanks to Daniel Mahler for finding this problem and proposing the fix
* lisp/babel/ob.el (unless): ensure `declare-function' is available in
all Emacsen
A quick example of accessing remote json data from Babel code blocks.
Evaluate the following to see a listing of parks in DC by ward.
#+source: dc-parks
#+begin_src emacs-lisp :var keys='(ward address) :var data=json(url="http://ogdi.cloudapp.net/v1/dc/RecreationParks?format=json")
(append
(list keys 'hline)
(mapcar
(lambda (lis) (mapcar (lambda (key) (cdr (assoc key lis))) keys))
(cdr (car data))))
#+end_src
* lisp/org-macs.el (org-not-nil): Return the value if not interpreted
as nil.
* lisp/org.el (org-entry-get):
(org-entry-get-with-inheritance): Interpret the value "nil"
as nil for properties.
Bernt Hansen writes:
> Carsten Dominik <carsten.dominik@gmail.com> writes:
>
> > On Jun 25, 2010, at 3:23 PM, Robert Goldman wrote:
> >
> > > Question: what is the proper way to get a NIL into a property? Are
> > > we
> > > to use () instead of "nil"? Or are property values always interpreted
> > > as strings?
> > >
> > > Apologies in advance if this is a stupid question!
> >
> > Not a stupid question at all.
> >
> > There is no way, currently. Property values are string - the only
> > way to make
> > org-entry-get return nil is to not have the property defined at all.
>
> I've wanted a similar thing in the past for the LOGGING property where
> the parent task has special logging set via the LOGGING property but I
> want to undo that for some of the child tasks so they use the default
> logging setup.
>
> Having a way to undefine a property would be good in general I think.
-Bernt
* lisp/org-macs.el (org-not-nil): New function.
* lisp/org.el (org-block-todo-from-children-or-siblings-or-parent):
Use `org-not-nil' to interpret a property value of nil.
Robert Goldman writes:
> I have found what I believe to be a bug in handling ordered subtasks.
> Here is the behavior:
>
> I have a top level set of tasks that is ordered.
>
> One of the outline items below the top level set is a grab bag of tasks
> that will be performed in parallel. So this task is NOT ordered
> (ORDERED: nil).
>
> The problem is that the blocking behavior from ordered tasks seems to be
> inherited from the top level task list into the second level of the
> outline, even though the ORDERED property at the second level is
> explicitly overridden.
>
> I am attaching an org file that displays this issue. To see the
> problem, put your cursor on the "Bar" task and attempt to change its
> status to DONE.
The problem was here that the value of the property is the string
"nil", which is of course not nil.
This patches introduces a special case to interpret "nil" as nil.
* lisp/babel/langs/ob-emacs-lisp.el
(org-babel-expand-body:emacs-lisp): removed extra call to
`org-babel-process-params' which was causing referenced code blocks
to be run multiple times
(org-babel-execute:emacs-lisp): now passing processed-params through
to `org-babel-expand-body:emacs-lisp' which keeps references from
being evaluated multiple times
* lisp/org-agenda.el (org-agenda-get-timestamps): No errors
while getting TODO state.
(org-agenda-highlight-todo): No error when no keyword has
been matched.
Eric Arneson writes:
> I've discovered a bug in `org-agenda-get-timestamps' wherein an active
> timestamp before the first headline causes it to fail. I realize that
> this is probably an error in my use of active timestamps, but there was
> no really handy error message and this bugged me for weeks.
>
> I'm not familiar enough with org-mode to know what the correct behavior
> should be here (it'd be nice to get an error message saying "Don't use
> active timestamps that way!"), but here's an example .org file that will
> trigger the bug:
>
> --8<---------------cut here---------------start------------->8---
> #+BEGIN: clocktable :maxlevel 3 :scope today
> Clock summary at [2010-06-20 Sun 13:09]
>
> | L | Headline | Time |
> |---+---------------------------------------+--------|
> | | *Total time* | *0:13* |
> |---+---------------------------------------+--------|
> | 1 | Track down funky bug <2010-06-20 Sun> | 0:13 |
> #+END:
>
> * Track down funky bug <2010-06-20 Sun>
> :LOGBOOK:
> CLOCK: [2010-06-20 Sun 12:43]
> CLOCK: [2010-06-20 Sun 12:30]--[2010-06-20 Sun 12:43] => 0:13
> :END:
> --8<---------------cut here---------------end--------------->8---
>
> I hope this can help somebody else track down the right place to fix
> this bug.
Thanks to Bernt Hansen for pointing this out
* doc/org.texi (Languages): updating require statements for the next
org-babel syntax
(Batch execution): updating require statements for the next
org-babel syntax
* lisp/babel/ob-exp.el (org-babel-exp-results): now checking to see if
return value of `org-babel-ref-literal' is equal to the null
indicator flag -- meaning it's now possible to accept a value of
null
* lisp/babel/ob-ref.el (org-babel-ref-parse): now checking to see if
return value of `org-babel-ref-literal' is equal to the null
indicator flag -- meaning it's now possible to accept a value of
null
(org-babel-ref-literal): now returning a null indicator flag when
the value is *not* a literal value, meaning it is possible to pass
in a literal value of null
Eric Schulte
Carsten Dominik
David Maus
Julien Danjou