Chris Randle writes:
> I have one giant Org-mode file for everything. I frequently use
> `C-c C-x b' to take the current node and show it in a new frame
> with narrow subtree so that I can concentrate on just that region
> of my file. Rather like hoist in GrandView, if anyone remembers
> that.
>
> My Org Manual (6.24b) says "The indirect buffer...will contain
> the entire buffer, but will be narrowed to the current
> tree. Editing the indirect buffer will also change the original
> buffer, but without affecting visibility in that buffer.
>
> I've noticed that, when working in the new frame, changing the
> TODO state of any item within the frame to DONE (when it is the
> currently clocked in item) does not stop the clock. Going back to
> my main frame and doing the same thing there on the same item
> does stop the clock.
>
> I haven't altered `org-clock-out-when-done', and Emacs reports
> its value as t.
This was caused by the fact that markers seem to point to the
base buffer always, so we need to check if the current buffer's
base buffer is equal to the marker buffer.
David Maus writes:
> When I start to clock a headline (C-c C-x C-i) that does not have a
> LOGBOOK drawer orgmode inserts one but removes the indentation of the
> first line below the headline:
>
> Example:
>
> * TODO Do something
> Do this, do that etc.
>
> after C-c C-x C-i becomes
>
> * TODO Do something
> :LOGBOOK:
> CLOCK: [2009-03-20 Fr 19:03]--[2009-03-20 Fr 19:03] => 0:00
> :END:
> Do this, do that etc.
Fixed with this commit, a patch written by Peter Jones.
Adam Elliott writes:
> When run in day-step mode, the clocktable header line for each day's
> table contains an active timestamp. I figure it should be an inactive
> timestamp, since otherwise I get a junk entry in the agenda each day
> (whatever heading was previous to the clocktable).
>
> I'm talking about the output from a spec such as the following:
>
> #+BEGIN: clocktable :block thisweek :step day
This commit is the patch Adam sent in.
Clock lines are now by default captured into the drawer LOGBOOK. This
means that, if state notes are also captured into a drawer, they will
be mixed with notes.
Wanrong Lin writes:
My TODO sequence is set up as following:
(setq org-todo-keywords '((sequence "TODO(t)" "STARTED(s!)"
"WAITING(w@/!)" "MAYBE(m/!)" "DELEGATED(g@/!)"
"DEFERRED(d!/!)" "HOLD(h!/!)" "|" "DONE(x)" "CANCELED(c)")))
The state change logging is great, but I wonder whether we can
further improve it:
1. Can we also include the original state in the log message?
i.e.: instead of having - State "DEFERRED" [2009-02-11 Wed 11:38]
we can have
- State "DEFERRED" from "HOLD" [2009-02-11 Wed 11:38]
The message will be clearer, and useful even when somebody edited
the TODO keyword in place without using the "org-todo" command
(in that case, simply looking at all the "destination states" in
the log message does not give us the right information).
This strikes me like a good idea, so I have implemented it with this
commit.
Consider a file with 2 lines:
------------------
**** heading
------------------
Place the cursor at line 2 (where you can type). Then use C-c C-x C-i
to start a clock.
You have now 3 lines:
------------------
**** heading
CLOCK: [2009-02-07 sb 01:06]
------------------
However, the cursor is still placed at line 2, like before. I think
it would be more useful if it were moved to line 3 so that you can
start writing right away, just as before. This saves you the C-n
needed to move again to a blank line.
This commit implements exactly this request.
Daniel Clemente noticed that the clock drawer, when it is created for
the second clock entry, will swallow a plain list item after it,
because it thinks it might be a clock note.
This commit makes this function check for indentation. If the plain
list item is indented less than the last clock line, it will be
assumed that it does not belong to the clocking line, and the drawer
will not swallow the item.
David Bremner writes:
I have a clocktable that begins like this.
#+BEGIN: clocktable :maxlevel 2 :block 2009-W05 :scope agenda-with-archives
Clock summary at [2009-01-27 Tue 17:15], for week 2009-W04.
[contents snipped]
#+END:
Whatever week I put in :block, it puts one less in the title. It
seems actually gather the clock data from the right week, but the
title is wrong? Or I misunderstand something as usual :-).
There was a problem wit the week starting date.
William Henney writes:
If a heading has tags, then that heading's time summary
overlay (shown by C-c C-x C-d) is displayed using the
org-tag face. This looks a bit strange. Is it intended? It
is especially noticeable in my case, since I have my tags
shown in a smaller font.
This is cause by the fact that we use the `secondary-selection' face
here which only highlights but inherits the rest from what is below.
The idea was that these clock times should have the same color as the
headline they belong to, but this idea is defeated when a line has tags
with a very different face.
This commit introduces a separate face for this purpose, so that users
can customize it.
Unique identifiers for entries can now be used more efficiently.
Internally, a hash array has replaced the alist used so far to
keep track of the files in which an ID is defined. This makes it
quite fast to find an entry by ID.
There is now a new link type which looks like this:
id:GLOBALLY-UNIQUE-IDENTIFIER
This link points to a specific entry. When you move the entry to
a different file, for example if you move it to an archive
file, this link will continue to work.
The file /org-id.el/ contains an API that can be used to write
code using these identifiers, including creating IDs and finding
them wherever they are.
Org has its own method to create unique identifiers, but if the
system has /uuidgen/ command installed (Mac's and Linux systems
generally do), it will be used by default. You an also select
the method by hand, using the variable =org-id-method=.
If the ID system ever gets confused about where a certain ID is,
it initiates a global scan of all agenda files with associated
archives, all files previously known containing any IDs, and all
currently visited Org-mode files to rebuild the hash. You can
also initiate this by hand: =M-x org-id-update-id-locations=.
Running this command will also dump into the =*Messages*= buffer
information about any duplicate IDs. These should not exist, but
if you /copy/ an entry with its properties, duplicate IDs will
inevitably be produced. This is unavoidable in a plain text
system that allows you to edit the text in arbitrary ways, and a
portion of care on your side is needed to keep this system clean.
The hash is stored in the file =~/.emacs.d/.org-id-locations=.
This is also a change from previous versions where the file was
=~/.org=id-locations=. Therefore, you can remove this old file
if you have it. I am not sure what will happen if the =.emacs.d=
directory does not exists in your setup, but in modern Emacsen, I
believe it should exist. If you do not want to use IDs across
files, you can avoid the overhead with tracking IDs by
customizing the variable =org-id-track-globally=. IDs can then
still be used for links inside a single file.
IDs will also be used when you create a new link to an Org-mode
buffer. If you use =org-store-link= (normally at =C-c l=) inside
en entry in an Org-mode buffer, and ID property will be created
if it does not exist, and the stored link will be an =id:= link.
If you prefer the much less secure linking to headline text, you
can configure the variable =org-link-to-org-use-id=. The default
setting for this variable is =create-if-interactive=, meaning
that an ID will be created when you store a link interactively,
but not if you happen to be in an Org-mode file while you create
a remember note (which usually has a link to the place where you
were when starting remember).
Org-mode still has a few operations that do not work well when the
first line of a buffer is a headline. One was constructing the clock
table, but this one is eliminated by this patch.
This patch compacts the persistence code. It also make sure that no
variables outside Org's name space are created. Finally, it makes
sure that the resumed clock is not hidden after a restart of Emacs.
Saving the clock history and the running clock could lead to pointers
to non-existing buffer, or to dired buffers of directories. This
patch implements more consistency checks.
It also allows a new value for `org-clock-persist'. When this is
`clock', only the running clock, but not the entire clock history
is saved.
Org-mode produces summaries of clocked items in the form of Org-mode
tables. This patch implements the possibility to define formulas that
should be applied to the clock tables, in order to do additional
analysis.
Formulas for clock tables are supported in two ways.
First, a formula can simply be added by hand to a table. Part of this
patch makes sure that, when the previous version of the table contains
a #+TBLFM: line, it will be copied to the new version.
Secondly, the clocktable definition allows a new parameter
`:formula'. The string value of this parameter will be installed as
the formula line for the table. If a formula parameter is given, it
will overrule any previous formula line.
As a special case, using the symbol `%' as the formula will install a
formula that will compute the fraction of total time that was spent in
a subtree.
In both cases, the formulas will be immediately evaluated after the
table has been created.
Carsten Dominik
Bernt Hansen