This variable defaults to nil. When non-nil, this is the default
value when the user is prompted for a timer.
This patch also improves org-timer-set-timer so that the user can
replace the current timer by a new one.
Hello, Org mode hackers,
This patch defines a variable `org-agenda-persistent-filters'.
When it is set, filters persist from one agenda view to the next.
I've found this convenient when using tags for contexts like @home,
@net, etc., some of which commonly remain applicable for a while.
Thanks,
Thomas
From 052ef9205845c78cb24d6fea8f89484bbe12a528 Mon Sep 17 00:00:00 2001
From: Thomas Morgan <tlm@ziiuu.com>
Date: Fri, 23 Apr 2010 11:48:03 +0200
Subject: [PATCH] New option `org-agenda-persistent-filters'.
When set, keep filters from one agenda view to the next.
Tom writes:
> if I have a heading like this:
>
>
> ** TODO test task
> stuff
> SCHEDULED: <2010-05-15 Sat 07:35 +1d>
>
>
> Then an empty line is inserted below the heading (before "stuff") if
> org-indent-mode is on and logging is set like this:
>
>
> (setq org-log-repeat nil)
> (setq org-log-done 'time)
>
>
>
> I tested it with a clean config using only the settings above.
This patch fixes the problem first reported by Tassilo Horn in
[mid:87y6fhxc47.fsf@thinkpad.tsdh.de]. Problem was that
`org-refile-cache-get' returned an invalid refile target table after
the refile cache was cleared.
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.
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
Patch by David Maus:
> 1. Store and open link to Wanderlust folders.
>
> 2. Store link to Wanderlust message while visiting the message
> buffer.
>
> Up to now it was only possible to store a link to a message when
> point was in the message summary.
Patch by David Maus, who writes:
> Org enters an infinite loop when `org-replace-escapes' is called with
> a table containing a replace string that contains the escape sequence
> it should be replaced with.
>
> Example:
> ,----
> | (org-replace-escapes "%m" '(("%m" . "87zl0qq1f3.wl%maus.david@gmail.com")))
> `----
>
> I stumpled upon when I tried to store a link to a internet message
> whose message id contained the sequence "%m" (perfectly valid for a
> message id) while using "%m" as message description.
>
> Attached patch fixes this by
>
> 1. detecting such 'self reference' and replacing the offending
> sequence in the replace string by a string with a text property
> that contains the original sequence
>
> 2. replacing occurences of substrings with this text property by the
> original sequence.
Patch by Stephen Peters.
Stephen writes:
> When creating a table, I was noticing that the
> <colgroup><col>... provides useful alignment information based on
> whether or not the column has numbers in it. I think, however, that
> there is a mistake in this routine. Take, for example, the following
> table:
>
> | Id | Task | Developer | Estimate | Spent | Remaining | Comp.% | Updated |
> |-----+--------------+-----------+----------+-------+-----------+--------+-----------------|
> | 1 | Task One | SLP | 1 | 0 | 1 | 0 | SLP, 2010-04-27 |
> | 2 | Task Two | SLP | 1 | 0 | 1 | 0 | SLP, 2010-04-27 |
> | 3 | Task Three | SLP | 2 | 0 | 2 | 0 | SLP, 2010-04-27 |
> | 4 | Task Four | SLP | 2 | 0 | 2 | 0 | SLP, 2010-04-27 |
> | 5 | Task Five | SLP | .25 | 0 | 0.25 | 0 | SLP, 2010-04-27 |
> | 5.1 | Another Task | XML team | 0 | 1 | 0 | 0 | SLP, 2010-04-27 |
> | 6 | Task Six | SLP | .25 | 0 | 0.25 | 0 | SLP, 2010-04-27 |
> | 6.1 | More Tasks | DB team | 3 | 0 | 3 | 0 | SLP, 2010-04-27 |
> | 7 | Task Seven | SLP | 3 | 0 | 3 | 0 | SLP, 2010-04-27 |
>
> When the colgroup list is created for this table, it reads:
>
> <colgroup><col align="right" /><col align="left" /><col align="left" /><col align="right" /><col align="right" /><col align="left" /><col align="left" /><col align="left" />
> </colgroup>
>
> Note that the first columns are correct, but the last few are not. It
> should read right, left, left, right, right, right, right, left.
>
> I believe that this is due to the (< i nline) comparison within
> org-format-org-table-html, which is nonsensical because it's trying to
> compare a column number with a number of rows. I've attached a patch
> for the problem.
