Nicolas Goaziou writes:
> As I was saying in anoter post, it looks like there's something
> weird happening when using C-k in agenda view:
>
> 1. Create two new remember entries (i.e. test and test2) with the
> same tag (I used @office)
> 2. Narrow down the agenda view to only see the @office entries.
> 3. Kill the last but one entry (it should be "test") : both of
> "test" and "test2" disappear frow the view. Actually, "test2" is
> not properly killed, but it is scary nonetheless.
>
> It only happens with two last entries.
>
> Is anyone able to reproduce this ?
All export commands now push the result to the kill ring by default.
This is subject to the variable `org-export-push-to-kill-ring'.
Also, this commit adds a new variable
`org-export-show-temporary-export-buffer' which can be used to turn
off the display of the temporary buffer containing the exported text.
Since this stuff is now automatically pushed onto the kill ring, some
people might prefer not to see this buffer.
Mikael Fornius writes:
> This is my suggestion of an implementation of min/mean/max computation
> in columnview summaries. If you like it feel free to use it.
>
> New operators: {min}, {max} and {mean} possibly prefixed with : for use
> with timevalues.
>
> Example from my running exercise diary:
>
> #+COLUMNS: %DISTANCE{+;%.1f} %HEARTRATE{mean;%.1f} %SPEED{:min} %CALORIES{+}
>
> Gives a colview with summaries:
>
> total distance, mean heartrate, fastest speed (min/km) and total
> calories.
>
> I have tested it on emacs-23 and it works well for me now, also with the
> interactive colview functions.
>
> But you never know really. ;-) Anyway, there should not be any emacs-23
> specific elisp code added afik.
>
> (Because I do not use xemacs I have not tested it with xemacs but the
> small changes I made should be compitable to both xemacs and emacs. I
> would appreciate if someone on this list who uses xemacs will give it a
> try for me. Thanks!)
>
> (This fix also opens up for using user defined lisp functions to
> calculate colview summaries, but I am not sure if that is something
> useful. Like this:
>
> (defun std (&rest values)
> "Compute standard deviation."
> ...)
>
> #+COLUMNS: %DATA{eval:std}
>
> If someone finds this attractive it would now be easy to implement as well.)
>
Setting the new option `org-hierarchical-todo-statistics' to nil will
make TODO statistics to be computed recursively. This means, not only
the direct children of a node contribute to its TODO statistics, but
the entire subtree.
You can also set the COOKIE_DATA property and add the word "recursive"
there to get recursive statistics for a specific tree.
Publishing a project with prefix argument to
force publishing was broken. Actually, the entire interactive side of
this function was implemented badly. Fixed now.
Hsiu-Khuern Tang writes:
> Hi Carsten,
>
> You recently changed org-edit-src-code to use a separate buffer
> instead of an indirect buffer. One side effect of this is that I
> can no longer edit several code examples at the same time:
> opening the second buffer will silently discard any changes made
> in the first. I would prefer this behavior: when opening the
> second edit source buffer, write any changes in the first buffer
> to the originating Org buffer (but don't save it, of course).
>
> Another approach is to use different buffer names.
The better approach is clearly to allow several buffers, now
implemented with this commit.
Harri Kiiskinen writes:
> There is an elusive bug in the ICal export functions. To
> demonstrate it, open this file, allow for the use of the local
> variable, and run 'org-export-icalendar-this-file'. What I get is
> the message "Wrong type argument: stringp, nil"
>
> -----------------------------
> #+FILETAGS: test
> * TODO header
>
> # Local Variables:
> # org-use-tag-inheritance: "^[t]"
> # End:
> -----------------------------
>
> Now, the funny thing is, that if you change the filetag from
> "test" to "est", close the file, and open it again, the file will
> be exported fine! It seems, that if the filetag does match the
> regular expression in org-use-tag-inheritance, then the result is
> error.
This bug was due to a missing save-match-data around a call to
org-get-tags-at. However, when studying this bug it turned out
that explicitly checking for the archive tag is not needed,
because we already have a call to `org-agenda-skip' in the same
loop.
Peter Frings writes:
> Good day, org-ers
>
> I have seen a *small* problem in the Agenda's log mode.
>
> Org-mode version 6.26d
> GNU Emacs 22.3.1 (i386-apple-darwin9.5.0, Carbon Version 1.6.0) of 2008-11-01
>
>
> I have this in time-sheets.org:
>
>
> * Project AI
> ** Enhancement PT <2009-04-30 Thu 10:00-11:00 +1w>
> CLOCK: [2009-05-14 Thu 09:55]--[2009-05-14 Thu 10:45] => 0:50
>
>
> But, the Agenda shows this:
>
> Day-agenda (W20):
> Thursday 14 May 2009
> 9:00...... ----------------
> planning: 9:12- 9:55 Clocked: (0:43) BUSY Notifications
> time-sheet: 10:00-11:00 Clocked: (0:50) Enhancement PT
> time-sheet: 10:00-11:00 Enhancement PT
> 10:00...... ----------------
> 11:00...... ----------------
>
He is right. Progress lines should never take their
time from the headline, always only from the triggering line.
krick
Carsten Dominik