* 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/org-macs.el (org-rm-props): Add org-emphasis to the properties
that must be removed.
* lisp/org.el (org-do-emphasis-faces): Add org-emphasis property to
items that have emphasis done wit font-lock.
(org-fontify-entities): Do not do anything in commented lines.
(org-unfontify-region): Decompose the region as well, because we do
composition during font-lock.
(org-raise-scripts): Do nothing inside an emphasis string.
Reported by Eric Fraga in http://article.gmane.org/gmane.emacs.orgmode/25940
Peter Westlake writes:
> Could I request this as a small feature enhancement, please?
> Commands like org-refile have an agenda equivalent so that
> the same keys work in the agenda, and it would be very nice
> to be able to store a link to an item that way as well.
Many different people want to set many different variables in a
buffer-local way for export. This cannot be done with file variables,
because the Org buffer is not current while the exporter is running.
Lots of variables can be set with the #+OPTIONS lines, but finding
abbreviations goes only so far.
Therefore we have now a general mechanism that can be used to bind
variables during export operations.
a line like: #+BIND: variable value
will bind the variable to value. For example,
the line
>> #+OPTIONS: toc:nil
can now equivalently be written as
>> #+BIND: org-export-with-toc nil
Thomas Morgan writes:
> I just tried exporting an Org file with LaTeX fragments to HTML
> on a computer that doesn't have dvipng. There were error messages
> in *Messages* ("Failed to create png file..."), but this wasn't
> obvious to me at first glance because those messages were replaced
> in the echo area by "Exporting... done" before I could see them.
>
> So I was wondering, is there a good way to make the user aware of
> those errors? Maybe by printing "Exporting... done (with errors)"?
There is now a better error message when either the latex or the
dvipng program does not exist.
Carsten Dominik
Bernt Hansen