Mikael Fornius writes:
> This is my suggestion of an implementation of min/mean/max computation
> in columnview summaries. If you like it feel free to use it.
>
> New operators: {min}, {max} and {mean} possibly prefixed with : for use
> with timevalues.
>
> Example from my running exercise diary:
>
> #+COLUMNS: %DISTANCE{+;%.1f} %HEARTRATE{mean;%.1f} %SPEED{:min} %CALORIES{+}
>
> Gives a colview with summaries:
>
> total distance, mean heartrate, fastest speed (min/km) and total
> calories.
>
> I have tested it on emacs-23 and it works well for me now, also with the
> interactive colview functions.
>
> But you never know really. ;-) Anyway, there should not be any emacs-23
> specific elisp code added afik.
>
> (Because I do not use xemacs I have not tested it with xemacs but the
> small changes I made should be compitable to both xemacs and emacs. I
> would appreciate if someone on this list who uses xemacs will give it a
> try for me. Thanks!)
>
> (This fix also opens up for using user defined lisp functions to
> calculate colview summaries, but I am not sure if that is something
> useful. Like this:
>
> (defun std (&rest values)
> "Compute standard deviation."
> ...)
>
> #+COLUMNS: %DATA{eval:std}
>
> If someone finds this attractive it would now be easy to implement as well.)
>
Setting the new option `org-hierarchical-todo-statistics' to nil will
make TODO statistics to be computed recursively. This means, not only
the direct children of a node contribute to its TODO statistics, but
the entire subtree.
You can also set the COOKIE_DATA property and add the word "recursive"
there to get recursive statistics for a specific tree.
Publishing a project with prefix argument to
force publishing was broken. Actually, the entire interactive side of
this function was implemented badly. Fixed now.
Hsiu-Khuern Tang writes:
> Hi Carsten,
>
> You recently changed org-edit-src-code to use a separate buffer
> instead of an indirect buffer. One side effect of this is that I
> can no longer edit several code examples at the same time:
> opening the second buffer will silently discard any changes made
> in the first. I would prefer this behavior: when opening the
> second edit source buffer, write any changes in the first buffer
> to the originating Org buffer (but don't save it, of course).
>
> Another approach is to use different buffer names.
The better approach is clearly to allow several buffers, now
implemented with this commit.
Harri Kiiskinen writes:
> There is an elusive bug in the ICal export functions. To
> demonstrate it, open this file, allow for the use of the local
> variable, and run 'org-export-icalendar-this-file'. What I get is
> the message "Wrong type argument: stringp, nil"
>
> -----------------------------
> #+FILETAGS: test
> * TODO header
>
> # Local Variables:
> # org-use-tag-inheritance: "^[t]"
> # End:
> -----------------------------
>
> Now, the funny thing is, that if you change the filetag from
> "test" to "est", close the file, and open it again, the file will
> be exported fine! It seems, that if the filetag does match the
> regular expression in org-use-tag-inheritance, then the result is
> error.
This bug was due to a missing save-match-data around a call to
org-get-tags-at. However, when studying this bug it turned out
that explicitly checking for the archive tag is not needed,
because we already have a call to `org-agenda-skip' in the same
loop.
Peter Frings writes:
> Good day, org-ers
>
> I have seen a *small* problem in the Agenda's log mode.
>
> Org-mode version 6.26d
> GNU Emacs 22.3.1 (i386-apple-darwin9.5.0, Carbon Version 1.6.0) of 2008-11-01
>
>
> I have this in time-sheets.org:
>
>
> * Project AI
> ** Enhancement PT <2009-04-30 Thu 10:00-11:00 +1w>
> CLOCK: [2009-05-14 Thu 09:55]--[2009-05-14 Thu 10:45] => 0:50
>
>
> But, the Agenda shows this:
>
> Day-agenda (W20):
> Thursday 14 May 2009
> 9:00...... ----------------
> planning: 9:12- 9:55 Clocked: (0:43) BUSY Notifications
> time-sheet: 10:00-11:00 Clocked: (0:50) Enhancement PT
> time-sheet: 10:00-11:00 Enhancement PT
> 10:00...... ----------------
> 11:00...... ----------------
>
He is right. Progress lines should never take their
time from the headline, always only from the triggering line.
Benjamin Andresen writes:
> I was curious as to why a value such log-mode wasn't customizable
> to be run on start-up as follow-mode and clock-report-mode are.
>
> If Carsten thinks this is a good idea, I've attached a patch that
> may shave of 5 seconds of him adding it. It applies cleanly to
> current git HEAD.
This commit applies Beanjamin's patch
There is now a new export function, `org-export-as-org', which
basically creates a copy of the Org file with things like archived
trees, commented trees, and trees deselected by export tags,
stripped.
This commit adds:
{{{date(FORMAT)}}} current date/time, formatted with
`format-time-string'
{{{modification-time(FORMAT)}}} date/time of last modification of
file, formatted with `format-time-string'
{{{input-file}}} the file name of the source Org file.
entries.
Guy Wiener writes:
> Hello everyone,
>
> I use orgmode to write down TODO tasks with dependencies (using
> org-enforce-todo-dependencies). I want to export the tasks to an
> iCalendar file, but *without* the blocked tasks (i.e, tasks that have
> unfinished dependencies). The agenda view hides these tasks if you set
> org-agenda-dim-blocked-tasks. It there a way to configure the
> iCalendar export to ignore these tasks too, like in the agenda view?
This commit implements this, when the value of
`org-icalendar-include-todo' is the symbol `unblocked'.
The commit implements a general mechanism for providing special
(e.g. completion) support for specific link types when entering links
with `C-c C-l'. After calling `C-c C-l', you may now press RET after
inserting a link prefix, and Org will look for a function
`org-PREFIX-complete-link'. Such functions may be defined for any
link types, including link abbreviations. Currently, Org has
`org-file-complete-link' for file name completion, and
`org-bbdb-complete-link' for completion of record names from BBDB.
Peter Westlake writes:
> On Fri, 8 May 2009 06:24:54 +0200, "Carsten Dominik"
> <carsten.dominik@gmail.com> said:
>
> I anyone could make an example that allos me to reproduce this
> problem, then I might be able to fix it.
>
> It's trivial:
>
> * top
> ** sub 1
> Set org-cycle-include-plain-lists.
> Type TAB on this line, and the whole of top gets folded.
>
> ** sub 2
> This entry is not needed to reproduce the bug. It just
> makes it more visible.
There was indeed a bug, I think it is fixed now.
