Daniel S. Sinder writes:
> Here's an "odd" problem when I call org-archive-subtree with a
> prefix argument. It seems that DONE subtrees are not found if
> I'm using odd level headlines. I've tried this minimal test
> case:
>
> ---- begin: test case 1 ----
> #+STARTUP: hidestars odd
>
> * DONE Project 1
> *** DONE Task 1.1
> *** DONE Task 1.2
> ---- end: test case 1 ----
>
> If I put the cursor on the level-1 headline and do C-u C-c C-x
> C-s, I am not prompted if I want to archive the level-3 children.
> However, if I remove 'odd' from the STARTUP line and move the
> level 3 headlines to level 2, so I have this:
>
> ---- begin: test case 1 ----
> #+STARTUP: hidestars
>
> * DONE Project 1
> ** DONE Task 1.1
> ** DONE Task 1.2
> ---- end: test case 1 ----
>
> then a repeat of the same command (C-u C-c C-x C-s) correctly
> asks if I want to archive the two level-2 headlines.
>
> I've removed my personal customizations and the problem does not
> go away.
The following keys now do archiving
C-c C-x C-a archive using the command specified in
`org-archive-default-command'
This variable is by default set to `org-archive-subtree', which means
arching to the archive file.
The three specific archiving commands are available through
C-c C-x C-s archive to archive file
C-c C-x a toggle the archive tag
C-c C-x A move to archive sibling
These bindings work the same in an Org file, and in the agenda.
In addition:
- In the agenda you can also use `a' to call the default archiving
command, but you need to confirm the command with `y' so that this
cannot easily happen by accident.
- For backward compatibility, `C-c $' in an org-mode file, and `$' in
the agenda buffer continue to archive to archive file.
This skips over blank lines preceeding the next task when archiving a task or
subtree. This allows us to use a keyboard macro to remember the archive key
sequence incantation and skips to the next heading so we don't accidentally
archive the wrong task.
This fixes an issue with blank line handling. Tasks which have blank lines
following them do not include the blank lines -- they are part of the following
task. This moves the point forward to the next visible headline so that if we
repeat the archive operation it affects the following task and not the previous
one by mistake.
Org erroneously filed top-level headings as level 2, because it
assumes that if should file below some heading. However, if there is
no heading to file under, this should be turned off.
Patch by igrekster.
Sometimes archiving a task displays the next task heading after ... at the
end of a folded task. This keeps the next task the cursor is on starting
in column 1 which feels more natural.
Matt Lundin writes:
I had one more question/request concerning archives. Would
it perhaps be possible to enable the file name
substitution (i.e., "%s") after the double semi-colon, so
that the file name can be used as a headline within the
archive file? My ideal setup would be to have a single
archive file for each year's work, with headlines named
according to the original files of the archived subtrees.
E.g.,
,----
| * finances.org
| ** archived item
| * notes.org
| ** archived item
| ** another archived item
`----
This commit does implement this request.
Matt Lundin writes:
When I have multiple org files archive to a single file, as in
,----
| (setq org-archive-location "~/2009.org_archive::")
`----
I find that including archive files in the agenda display (C-u v)
results in multiple identical entries in the agenda display (in my
case, when doing a word search).
In fact, the number of duplicate lines exactly matches the number of
agenda files that archive to that file (in my case 16). Is the agenda
function perhaps searching the archive file once for each of the
agenda files and then displaying the results as separate lines?
Indeed, when putting together the list o archive files to search,
Org did not check for duplicates. This commit implements
uniquification of the list.
Calling `org-archive-to-archive-sibling' caused problems when used
several times in a row. The new killed subtree would be appended to
the current head of the kill-ring, instead of being pushed there. The
reason for this is that the command `kill-region', which is called by
`org-cut-subtree' changes the variable `this-command', so that during
the next archive command, `kill-region' will think that the previous
command was also a kill and do the append.
Normally this is wanted, to make sure that several kill commands
create one big yank string. But in this case it has to be avoided.
The patch fixes the problem by let-binding (and therefore protecting)
the value of `this-command' around the call to `org-cut-subtree'.
Reported by Bernt Hansen.
Carsten Dominik
Bernt Hansen