Tassilo Horn writes:
> Hi all,
>
> I've just discovered the iCalendar export and use that to have a
> visually appealing read-only agenda in KOrganizer. Basically, the
> export seems perfect except for one thing.
>
> When I have an org entry like
>
> * Test :some:tags:here:
>
> the corresponding VEVENT will have the whole org heading including the
> spaces and the tag string as SUMMARY (unless the entry has a SUMMARY
> property). Having the tags there might be ok (although by default they
> are also set as CATEGORY), but the spaces between the heading title and
> the tags should be compacted.
Patch by Bernt Hansen:
> When org-clock-report-include-clocking-task is set we always add the
> current clocking task to the clock report. This is incorrect if you
> are looking at an agenda clock report for a time range that does not
> include the current clocking task (e.g. yesterday or last week).
>
> Now we only include the current clocking task if the clock report
> date range includes the current clocking task start time.
i/q/C-g Ignore this question; the same as keeping all the idle time.
k/K Keep X minutes of the idle time (default is all). If this
amount is less than the default, you will be clocked out
that many minutes after the time that idling began, and then
clocked back in at the present time.
g/G Indicate that you \"got back\" X minutes ago. This is quite
different from 'k': it clocks you out from the beginning of
the idle period and clock you back in X minutes ago.
s/S Subtract the idle time from the current clock. This is the
same as keeping 0 minutes.
C Cancel the open timer altogether. It will be as though you
never clocked in.
j/J Jump to the current clock, to make manual adjustments.
For all these options, using uppercase makes your final state
to be CLOCKED OUT.
Carsten Dominik <carsten.dominik@gmail.com> writes:
> Hi Sebastian,
>
> sorry for being slow. Could you do me a favor and send me the cache patch one
> more time - if possible updated to the current master.
>
> I am just not sure I have the right patch in my hands.
Hi Carsten,
no problem. The patch is attached.
Here is a list of my ChangeLog entries, redated to today:
2010-05-13 Sebastian Rose <sebastian_rose@gmx.de>
* org-publish.el (org-publish-cache): Use one big hashmap for
each project defined in `org-publish-project-alist'. The
hashmap will hold pairs of our timestamp-filenames and
timestamps, as well as pairs of source-paths and associated
plists for arbitrary values. Currently only the files title is
stored there.
The caching feature writes the information gathered during
publishing to disk and re-loads it from there the next time we
publish the same project. All those informations will hence
survive a restart of emacs.
One cache file per publishing project is used. The contents of
that file is the elisp that fills the new variable
`org-publish-cache'. The cache file is named according to the
project with `.cache' added and lives in
`org-timestamp-directory'.
* org-publish.el (initialize-files-alist): This function and
the variable `org-publish-files-alist' are not used anymore in
favour of the reloadable cache and the functions for handling
it. Removed therefor.
* org-publish.el (org-publish-validate-link) was not used
anywhere. Removed.
* org-publish.el (org-publish-get-base-files): Added the
variable `sitemap-requested' to avoid sorting where possible.
See also end of `org-publish-get-base-files-1'.
* org-publish.el (org-publish-get-files): This function is
not called anymore. Removed.
* org-publish.el (org-publish-get-project-from-filename) does
not depend on a list of files anymore. Instead of laoding all
files of all, we walk `org-publish-project-alist' until we
find a project, where the properties :base-directory, :recursive,
:base-extension, :include and :exclude match.
* org-publish.el (org-publish-file) takes an additional
parameter to avoid superfloues loading and writing of the
cache file when used to publish a part of a project.