* lisp/ob.el (org-babel-confirm-evaluate): adding a new :eval header
argument which can be used to control evaluation
* doc/org.texi (eval): adding documentation for the new :eval header
argument
patch by Stephen Eglen.
Here is a patch for the 'capture' section of org.texi . I've added a
few lines of @comments:
+@comment SJE: Should be Org file or Org-mode file (see prev two items)?
+@comment SJE: should these sentences terminate in period?
(i.e. the following lines in the table)
+@comment SJE: org-feed is not autoloaded - should that be mentioned?
Stephen
Thanks to Bernt Hansen for pointing this out
* doc/org.texi (Languages): updating require statements for the next
org-babel syntax
(Batch execution): updating require statements for the next
org-babel syntax
Bernt Hansen writes:
> I was talking to Jeff Stern about tags todo matching offlist and we
> think the documentation for tags-todo matching can probably be improved.
>
> The description of C-c a M at
> http://orgmode.org/manual/Matching-tags-and-properties.html
> states
>
> C-c a M
>
> Like C-c a m, but only select headlines that are also TODO items and
> force checking subitems (see variable
> org-tags-match-list-sublevels). To exclude scheduled/deadline items,
> see the variable org-agenda-tags-todo-honor-ignore-options. Matching
> specific TODO keywords together with a tags match is also possible,
> see Tag searches.
>
> When I read this I think TODO items is any todo keyword but this isn't
> the case. It is only non-done TODO state keywords. This makes
> tags-todo matching not work for finding tasks to archive (normally
> DONE | CANCELLED keywords in my setup)
>
> Should we explicitly state that 'headlines that are also TODO items'
> does not match DONE state keywords? Or alternatively should TODO items
> and DONE items be separate (and explicitly defined) in the documentation
> -- like org-todo-keywords and org-done-keywords?
>
> I still think 'TODO keyword' matches any todo keyword defined in
> org-todo-keywords and maybe I need to be re-educated :)
Bernt is right, and this patch tries to clarify the issue.
* lisp/org-agenda.el (org-agenda-action): Make `c' key call org-capture.
* lisp/org-capture.el: New file.
* lisp/org-compat.el (org-get-x-clipboard): Function moved here from
remember.el.
* lisp/org-mks.el: New file
* lisp/org.el (org-set-regexps-and-options): Allow statistic cookies as
part of complex headlines.
(org-find-olp): New argument THIS-BUFFER. When set, assume that the
OLP does not contain a file name.
source-code-chapter.texi is just reference.org with level 1 headings
replaced with @section, and level 2 headings replaced with
@subsection, and with a top level @chapter node. This file is included
in org.texi with an @include line for now.
* lisp/org.el (org-ctrl-k-protect-subtree): New option.
(org-kill-line): Protect hidden subtrees if the user wants it.
* doc/org.texi (Headlines): Mention the special behavior of C-k
in headlines.
Scott Otterson writes:
> For what must be the dozenth time, I've just accidentally deleted a
> large tree by typing C-k while in a headline.
>
> This is really easy to do because emacs users have "C-k deletes to the
> end of the line" worn deeply into their neural pathways -- it's so
> automatic for me that the keystroke is close to subconscious. A
> mistaken C-k is especially hard to detect because org-mode displays
> the result exactly like what your subconscious expects, that is, a
> collapsed headline is deleted to the end -- and the tree underneath is
> wiped out with no noticeable warning.
>
> Feature request: add an option preventing tree deletion with C-k
> without user confirmation. Actually, I'd like an option to prevent it
> period.
>
> If this option is already in there, then you're encouraged to tell me
> to RTFM. But then also please tell me where it is, because I can't
> find it.
Carsten replies
> This is now possible due to the variable
> `org-ctrl-k-protect-subtree'. But I predict that you are going to set
> it to nil again soon :D
* doc/org.texi (Subscripts and superscripts): Document that `C-c C-x \'
will also format sub and superscripts.
* doc/orgcard.tex: Document that `C-c C-x \'
will also format sub and superscripts.
* lisp/org.el (org-use-sub-superscripts):
(org-pretty-entities-include-sub-superscripts): Move here from
org-exp.el.
(org-set-regexps-and-options): Parse subscript option and set
`org-use-sub-superscripts' as a local variable.
(org-match-sexp-depth):
(org-create-multibrace-regexp):
(org-match-substring-regexp):
(org-match-substring-with-braces-regexp): Moved here from org-exp.el
(org-set-font-lock-defaults): Call `org-raise-scripts'.
(org-remove-font-lock-display-properties): New function.
(org-unfontify-region): Call
`org-remove-font-lock-display-properties'.
(org-script-display): New constant.
(org-raise-scripts): New function.
When turning on entity display with `C-c C-x \', sub- and superscripts
will also be displayed in a smaller font, and raised/lowered.
* doc/org.texi (Plain lists): Document
`org-list-demote-modify-bullet'.
* lisp/org-list.el (org-list-demote-modify-bullet): Improve docstring
by showing an example.
This change was triggered by a request by Livin Stephen Sharma.
* org-clock.el (org-dblock-write:clocktable): Return total time.
(org-clocktable-steps): Skip step when time is zero and the
:stepskip0 property is set.
Rainer Stengele writes:
> Creating clocktables for each day of a month is an excellent feature
> in org! Problem for me is that many resulting tables have a total
> time of 0:00. The problem is not really the zero time I spent but the
> appearance of the tables with zero total time.
>
> Is there a possibility to skip getting such tables? Rational: I do
> not need to show my boss or customer days where I spent 0:00 time on
> the project.
Now you can set :stepskip0 to achieve this.
Adam Elliott writes:
> I have attached a git patch against master that implements a new
> parameter to clock tables, "tags". This parameter is a tags-query as a
> string and is used to filter the headlines which are consulted when
> building the clock table.
>
> In my search of the archives to see if this feature already existed, I
> found a reference here:
> http://article.gmane.org/gmane.emacs.orgmode/17304
> suggesting it was difficult. The patch is not so large, though, so
> perhaps I am missing something.
>
> My rationale in implementing this feature was to keep track of the
> occasional task item that is not billable, yet still makes sense to
> include in the overall project structure. Of course I could just avoid
> clocking the task item, or manually delete clock lines before generating
> a report, but this feature reduces the chance for error; no doubt there
> are other workflows enabled with this feature as well. I don't make
> significant use of tags myself, but I know many do.
>
> In order to maintain a sensible report, headlines that don't match the
> tag filter may be included if they have descendants that do. Any time
> clocked directly on non-matching headlines, however, is excluded.
>
> Specifying even a simple filter noticeably slows down clock table
> generation for non-toy reports, particularly for clock table reports
> with :step. If there is no filter, though, there is no degradation in
> performance.
>
> Tag filter syntax is the standard one, as described at:
> http://orgmode.org/manual/Matching-tags-and-properties.html
> Only tags are considered at the moment, although I suspect querying
> against all properties would be possible (if even slower).
>
> Examples:
>
> * development
> CLOCK: => 1:00
> *** task 1
> CLOCK: => 1:00
> *** task 2 :must:
> ***** task 2a
> CLOCK: => 1:00
> ***** task 2b :mustnot:
> CLOCK: => 1:00
>
> Note I am using an unconventional but legal(ish) clock format for
> brevity. Clock tables are also pruned to only relevant lines.
>
> [1] #+BEGIN: clocktable
> | | *Total time* | *4:00* | | |
> |---+--------------+--------+------+------|
> | 1 | development | 4:00 | | |
> | 2 | task 1 | | 1:00 | |
> | 2 | task 2 | | 2:00 | |
> | 3 | task 2a | | | 1:00 |
> | 3 | task 2b | | | 1:00 |
>
> [2] #+BEGIN: clocktable :tags "must"
> | | *Total time* | *2:00* | | |
> |---+--------------+--------+------+------|
> | 1 | development | 2:00 | | |
> | 2 | task 2 | | 2:00 | |
> | 3 | task 2a | | | 1:00 |
> | 3 | task 2b | | | 1:00 |
>
> [3] #+BEGIN: clocktable :tags "-mustnot"
> | | *Total time* | *3:00* | | |
> |---+--------------+--------+------+------|
> | 1 | development | 3:00 | | |
> | 2 | task 1 | | 1:00 | |
> | 2 | task 2 | | 1:00 | |
> | 3 | task 2a | | | 1:00 |
>
> [4] #+BEGIN: clocktable :tags "must-mustnot"
> | | *Total time* | *1:00* | | |
> |---+--------------+--------+------+------|
> | 1 | development | 1:00 | | |
> | 2 | task 2 | | 1:00 | |
> | 3 | task 2a | | | 1:00 |
>
> [5] #+BEGIN: clocktable :tags "must+mustnot"
> | | *Total time* | *1:00* | | |
> |---+--------------+--------+------+------|
> | 1 | development | 1:00 | | |
> | 2 | task 2 | | 1:00 | |
> | 3 | task 2b | | | 1:00 |
>
> As you can see, in examples 2, 4, and 5, the time clocked on
> "development" itself is being removed. Example 2 illustrates the effect
> of tag inheritance.
>
> Adam
This behavior is now parallel to the treatment of outline nodes.
This commit also introduces another change. When an outline node or a
plain list item is folded by outline and contains hidden children,
M-left/right will refuse to act on this item. You must either open
the tree, or use the subtree commands M-S-left and M-S-right.
Based on a patch by Matti De Craene, but significantly modified after
a discussion involving Bernt Hansen and others.
Eric Schulte
Carsten Dominik
Stephen Eglen
Julien Danjou
Tom Dye
Dan Davison
Bastien Guerry
Christian Egli