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.
Patch by Christian Moe, who writes:
> It looks like support for formatting custom link types in LaTeX export
> is broken?
>
> I was trying to implement a custom link type with its own formatting
> function for HTML and LaTeX export, following the steps in
> org-bbdb.el.
>
> I've found that org-bbdb-export does not italicize bbdb links in
> LaTeX, nor does my own org-cite-export turn my custom =cite:= links
> into LaTeX =\cite{}= citations. Everything works fine in HTML export,
> but in LaTeX all custom link types get formatted as =\texttt{descr}=.
>
> I see that org-export-as-html and org-export-as-docbook look up
> org-link-protocols to get the function for formatting the link, but it
> seems that org-export-as-latex doesn't.
>
>
Karl Eichwalder writes:
> Consider the following two files:
>
> * 2009
> #+TBLNAME: 2009
> :PROPERTIES:
> :ID: ea32e5b5-31ba-468e-8e31-3e0d09696bb0
> :END:
> |-----+-------|
> | mm | km |
> |-----+-------|
> | all | 946.8 |
> |-----+-------|
>
> * 2010
> #+TBLNAME: 2010
> :PROPERTIES:
> :ID: e0df84c4-8abc-458f-a1ee-eb53eb71b4f0
> :END:
> |-----+-------+-------+-------|
> | mm | km | B km | G km |
> |-----+-------+-------+-------|
> | all | 249.4 | 429.2 | 678.6 |
> |-----+-------+-------+-------|
>
> * all
> :PROPERTIES:
> :ID: 44751a7f-73a4-4c07-b3c2-e3edb9042acd
> :END:
> #+TBLNAME: all
> |------+--------|
> | yyyy | km |
> |------+--------|
> | 2009 | |
> | 2010 | 678.6 |
> |------+--------|
> | all | 1625.4 |
> |------+--------|
> #+TBLFM: @2$2=remote(ea32e5b5-31ba-468e-8e31-3e0d09696bb0,$LR2);%.1f::@3$2=remote(2010,$LR4);%.1f::$LR2=vsum(@2$2..@-1);%.1f
>
> Then, in the 2010 file, eval the formula of the "all" table by pressing
> C-c C-c.
> ==>
>
> It takes the km value from the 2009 file, but also puts the cursor
> (point) into the 2009 file in front of the ID:
>
> * 2009
> #+TBLNAME: 2009
> :PROPERTIES:
> :ID: -!-ea32e5b5-31ba-468e-8e31-3e0d09696bb0
> :END:
> |-----+-------|
> | mm | km |
> |-----+-------|
> | all | 946.8 |
> |-----+-------|
>
> -=-=-=-=-=-=-=-=-=-=-=-=-=- cut here -=-=-=-=-=-=-=-=-=-=-=-=-=-
>
> I'd prefer if the point would stay in the 2010 file.
Baoqui Cui writes:
> "robut@iinet.net.au" <robut@iinet.net.au> writes:
>
> I very much like the idea of native inline image display in Org-mode but can't
> seem to make it work.
>
> Given a 6.36 snapshot or 6.36 release and these org file contents
>
> * Test image
> Test image
> [[Screenshot.png]]
>
>
> I hoped org would display that image after C-c C-x C-v. Rather Org-mode returns
> "No images to display inline".
>
> I've tried different ways of linking that image, different image formats,
> relative vs complete paths, and my regular .emacs vs a near empty one and
> always the same result. If I toggle iimage-mode the image displays fine per se
> but does not affect how Org-mode works.
>
> Seems clear I am missing something simple. What?
>
> I like the idea of inline image display too, but hit the similar
> problems. After reading the code in org.el, I found that the inline
> image file link has to start with either "file:" or "./".
>
> For example, the following two links are OK:
>
> [[file:~/images/myImage.png]]
> [[./figures/org-mode-unicorn.svg]]
>
> but the following two are not:
>
> [[Screenshot.png]]
> [[~/images/myImage.png]]
>
> Here is a small patch that seems to work well for me, but I'd like
> Carsten to check whether it may break anything