This lets you see how long has passed since the specified timestamp property
each entry. The three operators (@min, @max, @mean) show either the age of the
youngest or oldest entry or the average age of the children.
Alessandro Paccacio writes:
> I've an outline like this:
>
> * Project A
> ** TODO Task A-1 [0/3]
> *** TODO Subtask A-1-a
> *** TODO Subtask A-1-b
> *** TODO Subtask A-1-c
>
> where level 1 heading is the name of a project, level 2 heading is a
> generic task broken into three level 3 headings. As suggested in
> section 5.5 of the manual, I've hooked the org-summary-todo function
> to org-after-todo-statistics-hook, in order to automatically change
> the level 2 TODO to DONE when all the subtasks are DONE.
> Unfortunately, when I change to DONE the first subtask, an unexpected
> TODO is added to level 1 heading:
>
> * TODO Project A
> ** TODO Task A-1 [1/3]
> *** DONE Subtask A-1-a
> *** TODO Subtask A-1-b
> *** TODO Subtask A-1-c
>
> From now on, the switch TODO->DONE or DONE/TODO applies to level 1
> heading, even if the [/] cookie in level 2 is correctly updated:
>
> * DONE Project A
> ** TODO Task A-1 [3/3]
> *** DONE Subtask A-1-a
> *** DONE Subtask A-1-b
> *** DONE Subtask A-1-c
>
> Is there a way to apply the automatic change of TODO to the parent
> heading only, as below?
>
> * Project A
> ** DONE Task A-1 [3/3]
> *** DONE Subtask A-1-a
> *** DONE Subtask A-1-b
> *** DONE Subtask A-1-c
Martin Skjaeveland writes:
> Hi all,
>
> when I import the file
>
> --8<---------------cut here---------------start------------->8---
> -----------------
> | grandmother |
> =================
> | sim:Jackeline |
> | sim:Mona |
> -----------------
> --8<---------------cut here---------------end------------->8---
>
> using the command
>
> #+INCLUDE "grandmothers.txt" example
>
> and export to latex it turns into
>
>
> \begin{verbatim}
> -----------------
> | grandmother |
> \texttt{===============}
> | sim:Jackeline |
> | sim:Mona |
> -----------------
> \end{verbatim}
>
>
> I would like to remove \texttt{ }. I have tried different export
> option settings, but I can't make it work.
>
This bug resulted from a recent patch which made a prefix arg of 2 to
mean refile to the clock. However, I forgot to actually test the
value of the prefix arg...
Chris Randle writes:
> I've just noticed that creating a sparse tree with `C-c / r' is
> not displaying matches in my org file. It hasn't always been this
> way, I *think* things were working OK around 6.29, but it's hard
> to be sure.
>
> I've managed to pare my org file down to a few lines that
> demonstrate the problem
>
> ===============================
>
> * Customers
> ** Customer A
> *** Billing
> **** Support during September :ARCHIVE:
> ** Customer B
> 07964-xxxxxx
>
> *** Problem with Laptop
> ** Customer C
> *** Current Details
>
> *** Test of 07968 showing up
> ** Customer D
> 01673-xxxxxx
> 07968-xxxxxx
>
> *** Laptop slowdown fix
> spoolsv.exe at 99%
>
> ===================================
>
> Setting a sparse tree by regexp 0796[48] returns "3 match(es) for
> regexp 0796[48]", but the tree doesn't expand at the hit
> locations. If I manually expand the tree at the locations of the
> hits, the results are highlighted. It makes no difference if the
> hits are in a headline or in notes beneath a headline.
>
> Remove the ARCHIVE tag from the "Support during September"
> headline with `C-c C-x a' and redo the sparse tree. Everything
> now appears expanded as I'd expect.
Hmm, maybe the outline behavior of hide-subtree has changed???
Anyway, we now just use our own function for this.
Adam Spiers writes:
> The code for handling %^{PROP}p in org-remember templates seems to
> have a bug:
>
> ((equal char "p")
> (edebug)
> (let*
> ((prop (org-substring-no-properties prompt))
> (pall (concat prop "_ALL"))
> (allowed
> (with-current-buffer
> (get-buffer (file-name-nondirectory file))
>
> Here get-buffer can return nil, in which case `org-remember' fails
> with the error:
>
> Wrong type argument: stringp, nil
>
> It seems to be assuming that the non-directory part of the filename
> corresponds to the buffer name, but this is not guaranteed. Perhaps I
> noticed it because I am using uniquify.el ?
Doug Hellmann writes:
> Some calendar systems (Google, Zimbra) handle subscriptions to
> multiple calendars (or to an account) by grouping them under a single
> caldav directory in the calendar tree. org-mac-iCal assumes there is
> only one ics file created per caldav directory, so while it *creates*
> all of the needed merged ics files, it only copies one of them to
> ~/Library/Calendar before importing the contents into the diary.
Carsten Dominik
James TD Smith
John Wiegley
Eric Schulte
Dan Davison