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.
The target state can now be fixed locally with the REPEAT_TO_STATE
property, or globally with the variable `org-todo-repeat-to-state'.
This was a request by John Wiegley.
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.
This new code will search #+INDEX lines in the buffer. For LaTeX, it
will simple convert these into LaTeX \index{} commands. For other
backends, it will copy thee entries to a new file, with extension
orgx. These files can then later be post-processed to create the index.
Dan Davison writes:
> Bug report
> ==========
> If I have this:
>
> A [[file:zz.org::#mytarget][link]] to a target with a custom ID
>
> and export it to HTML, I get
>
> A <a href="zz.html##mytarget">link</a> to a target with a custom ID
>
> which (in firefox on linux) links to the file but does not jump to the
> target. However, if I change the '##' to '#' then firefox jumps to the
> correct location. Is this an org bug?
>
> Very tentatively proposed patch
> ===============================
> I've investigated a bit (notes below), resulting in this proposed patch:
>
> --8<---------------cut here---------------start------------->8---
> diff --git a/lisp/org-html.el b/lisp/org-html.el
> index aa70408..5ee5b19 100644
> --- a/lisp/org-html.el
> +++ b/lisp/org-html.el
> @@ -1110,7 +1110,7 @@ lang=\"%s\" xml:lang=\"%s\">
> (abs-p (file-name-absolute-p filename))
> thefile file-is-image-p search)
> (save-match-data
> - (if (string-match "::\\(.*\\)" filename)
> + (if (string-match "::#?\\(.*\\)" filename)
> (setq search (match-string 1 filename)
> filename (replace-match "" t nil filename)))
> (setq valid
> --8<---------------cut here---------------end--------------->8---
>
> Doc patch
> =========
> The link above (file:zz.org::#mytarget) was created by C-c l on a
> heading with a CUSTOM_ID property. However, I couldn't see where in the
> manual links of this form are documented. Do we need to add this link
> type to section 4.7 "Search options in file links", e.g.
>
> --8<---------------cut here---------------start------------->8---
> diff --git a/doc/org.texi b/doc/org.texi
> index f49f056..c8cc1a5 100644
> --- a/doc/org.texi
> +++ b/doc/org.texi
> @@ -3116,6 +3116,7 @@ link, together with an explanation:
> [[file:~/code/main.c::255]]
> [[file:~/xx.org::My Target]]
> [[file:~/xx.org::*My Target]]
> +[[file:~/xx.org::#my-custom-id]]
> [[file:~/xx.org::/regexp/]]
> @end example
>
> @@ -3130,6 +3131,8 @@ link will become an HTML reference to the corresponding named anchor in
> the linked file.
> @item *My Target
> In an Org file, restrict search to headlines.
> +@item #my-custom-id
> +Link to a heading with a @code{CUSTOM_ID} property
> @item /regexp/
> Do a regular expression search for @code{regexp}. This uses the Emacs
> command @code{occur} to list all matches in a separate window. If the
> --8<---------------cut here---------------end--------------->8---
>
> Notes
> =====
> At line 1134 of org-html.el there is
>
> (setq thefile (concat thefile "#"
> (org-solidify-link-text
> (org-link-unescape search)))))
>
> during evaluation of which 'search is bound to "#mytarget", which
> suggested that the problem might be in the regexp parsing creating
> 'search.
Carsten Dominik
Eric Schulte
Tom Dye
Dan Davison
Bastien Guerry
Christian Egli