* lisp/org-latex.el (org-export-latex-fixed-width): now checking
org-example rather than org-protected on verbatim export, because by
default all ": " prefixed lines are marked protected
thanks to Christopher Allan Webber for catching this
* lisp/babel/langs/ob-python.el (org-babel-python-table-or-string):
now more careful not to replace "None"s which are not isolated
portions of lists
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.
