Some of the standard export options are now defined in backend
specific files. This commit makes sure that building the options
property list will not cause an error because of unneeded (for the
backend) undefined variables.
Samuel Wales writes:
> A lower case version of a todo kw at the beginning of a
> headline, when in lower case, causes sort to ignore the
> word.
>
> Also, setting priority with shift down causes the cookie to
> be inserted in the wrong place.
Both problems are address in this commit.
Remember and refile processing does not require a task. This change
removes the unneeded default task.
This supports a workflow where new remember tasks and notes go into a
mostly empty file which just has #+FILETAGS: at the top and nothing
else.
This workflow has a minimal number of remember templates
- one for new tasks and (filed in tasks.org)
- one for new notes (filed in notes.org)
- one for phone calls (filed in phone.org)
New tasks are added as top-level tasks to the end of these files and
the #+FILETAGS: REFILE header causes each task to be easy to find.
All tasks in these files are refiled to a more appropriate org file at
a later time.
The following contributed packages are (partially) obsolete.
org-browser-url.el
org-annotation-helper.el
The functionality of both these packages is a subset of
org-protocol.el, which is now part of the Emacs core
and is recommended.
org-depend.el
A significant fraction of the org-depend functionality
dependence on siblings, children, and parents) is now
built-in into the Org core. Org-depend remains
in the distribution as a proof-of-concept fro complex
and remote dependencies.
org-interactive-query.el
I believe that much of what this package was build for
is now available with tag filtering.
These packages are now marked in org-modules as such.
The command org-reload did not only reload any loaded files, but all
lisp files in the Org distribution. Also, it actually never reloaded
any files from the contrib directory. Both of these problems are now
fixed.
Mapping call a function for each matching entry. So far this has
always assumed that the entry stays in the buffer and search can
continue from there. However, when the mapper function removes the
tree, more control is needed to specify from where the search should
continue.
The action function handed to the mapping function can now set the
variable `org-map-continue-from' to the position from where mapping
should continue.
Daniel Hochheimer writes:
> It seems there is a bug in the handling of simple dependencies.
> I think an example tree is the best solution, to show you the bug:
>
> * Projects
> #+CATEGORY: Projects
> *** TODO foo bar project
> :PROPERTIES:
> :ORDERED: t
> :END:
> ***** TODO foo subproject :FooSubproject:
> ******* TODO Task 1
> ***** TODO bar subproject :BarSubproject:
> ******* TODO Task 1
>
> This is in my .emacs file:
> (setq org-enforce-todo-dependencies t)
> (setq org-agenda-dim-blocked-tasks 'invisible)
> (setq org-odd-levels-only t)
>
> the expected global todo agenda view imho is:
>
> Projects: Task 1 :FooSubproject:
>
> but actual it is unfortunately:
>
> Projects: Task 1 :FooSubproject:
> Projects: Task 1 :BarSubproject:
>
>
> Imho "Task 1" from "bar subproject" should not be visible,
> because "bar subproject " is blocked because of the
> ORDERED property (therefore it's childs should be blocked, too)
>
>
> Is it easy / possible to fix this bug? My whole GTD system is
> heavily based on such project / subproject-Constructs. But with
> this bug my global todo agenda view is unfortunately "polluted"
> a little bit with tasks from projects that shouldn't be active.
After some back and forth, Daniel convinced me, and this is now done
correctly.
Carsten Dominik
Bernt Hansen