Jan Bcker writes:
> If you have a headline with an elisp code block containing the following
> line:
>
> " :ID:"
>
> the HTML code will be garbled at the beginning of the headline.
>
> I have attached a minimal test case and the resulting HTML file. The
> #+OPTIONS: line is not needed, but is included to make the HTML file
> less cluttered.
>
> There has to be whitespace between the " and :ID: and the string must be
> ended on the same line. For example, these lines trigger the bug:
>
> " :ID:"
> " :ID:"
> " :ID: garble-my-html"
>
> while these do not:
>
> ":ID:"
> ":ID: garble-my-html"
> " :ID:
>
The definition of "makes sense is here:
- either the user is logging repeats (org-log-repeat)
- or the entry contains clock data, in which case the LAST_REPEAT is
needed to display clocking time properly.
Request by Dan Griswold, with some support from Bernt Hansen
Patch by Peter Jones, following a bug report by Xiao-Jong Jin, who wrote:
> If you have the follow org file
>
> * test crypt :crypt:
> ** subheading 1
> text 1
> ** subheading 2
> text 2
>
> with setup as
>
> (require 'org-crypt)
> (setq org-tags-exclude-from-inheritance '("crypt"))
> (setq org-crypt-key "CBC0714E") ; my key
>
> On calling org-encrypt-entry on the first head line, only
> subheading 1 get encrypted, subheading 2 remains plain text.
> But, if you add an empty line or some text under the first
> heading, both subheading 1 and 2 are encrypted.
By David Maus.
The gist of the extended capabilities:
- Remove filter conditions for messages in a filter folder
If customization variable `org-wl-link-remove-filter' is non-nil,
filter conditions are stripped of the folder name.
- Create web links for messages in a Shimbun folder
If customization variable `org-wl-shimbun-prefer-web-links' is
non-nil, calling `org-store-link' on a Shimbun message creates a
web link to the messages source, indicated in the Xref: header
field.
- Create web links for messages in a nntp folder
If customization variable `org-wl-nntp-prefer-web-links' is
non-nil, calling `org-store-link' on a nntp message creates a web
link either to gmane.org if the group can be read trough gmane or
to googlegroups otherwise. In both cases the message-id is used as
reference.
- Open links in namazu search folder
If `org-wl-open' is called with one prefix, WL opens a namazu
search folder for message's message-id using
`org-wl-namazu-default-index' as search index. If this variable is
nil or `org-wl-open' is called with two prefixes Org asks for the
search index to use.
Regards,
-- David
Conflicts:
lisp/ChangeLog
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.
Patch by Matt Lundin
Matt writes:
> The missing piece of the puzzle is integration with "diary" and
> "cal-tex" functions via the org-diary sexp. I have found org-diary to be
> excruciatingly slow when called for anything more than a couple of days.
> I have the following line in my diary file:
>
> &%%(org-diary :timestamp :sexp)
>
> If I try to view 20 or so upcoming days in the diary by typing C-u 20 d
> on a date in the calendar, it can take upwards of 30 seconds to generate
> the diary display. This is of little consequence, since I can, after
> all, simply use the custom agenda command. But I often want to print out
> a nice LaTeX calendar of my appointments with cal-tex-cursor-month. And
> that takes upwards of 50 seconds (see attached elp-results file).
>
> Judging from the elp-results, the culprit seems to be
> org-prepare-agenda-buffers (46 seconds), which is called 31 times (once
> for each day). It seems to me that since org-diary is being called 31
> times in quick succession by the same function (diary-sexp-entry), one
> should only need to call org-prepare-agenda-buffers once.
>
> The only solution I could see to this problem was to add a test to see
> if org-diary had been called less than 1 second ago. Thus, I added the
> variable org-diary-last-run-time and a conditional in org-diary that
> only runs org-prepare-agenda-buffers if org-diary-last-run-time is less
> than 1 second in the past.
>
> With the patch, it now takes appr. 5 seconds to generate the LaTeX
> calendar with cal-tex and org-prepare-agenda-buffers is called only
> once.
By default, title, author, date and email lines appear in dark blue
with the initial keywords greyed out. The title is in a larger font
than the others. This is implemented by the following new faces:
org-document-title
org-document-info
org-document-info-keyword
In addition, the variable org-hidden-keywords can be used to make the
corresponding keywords disappear.
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.
Magnus Henoch writes:
> This patch has been sitting in my tree for a while... It's a fix to
> org-map-dblocks, to make it use save-excursion instead of remembering
> position values. I need this since I have a dblock function that
> asynchronously updates dblocks from HTTP responses, and some dblocks
> ended up getting updated twice or thrice.
[...]
> My dblock-write function calls url-retrieve, to asynchronously retrieve an
> HTML page. The callback function I pass to url-retrieve will then fill
> in the information I need into the dynamic block.
>
> So in the following case:
>
> * Find start of dblock 1, store as pos
> * Make HTTP request for dblock 1
> * Go back to pos
> * Find end of dblock 1
> * Find start of dblock 2, store as pos
> * Make HTTP request for dblock 2
> * Asynchronous event: HTTP response for dblock 1 arrives, insert lots of
> data in dblock 1
> * Go back to pos
> * Find end of dblock 2
>
> the last step will actually find the end of dblock 1, if the amount of
> data inserted in dblock 1 is great enough that pos suddenly points
> inside it. (Then it will of course find dblock 2 again, request its HTML
> page again, and thus insert the data twice.)
>
> An equivalent fix would be to make pos a marker instead.
Patch by David Maus, who writes:
> Attached patch for org-attach-commit in org-attach.el removes the
> dependency on the xargs command to remove files in the repository that
> were deleted in the attachment directory.
>
> Simply capture output of git ls-files --deleted -z in a temporary
> buffer, get the filenames from there via string-split and call git rm
> on each single file.
Keith writes:
> I noticed something strange and I think it's might be a bug converting
> to tex file. I've been trying to put a special symbol inside a
> bracket, e.g.
>
> air temperature (degree Celsius)
>
> and the symbol should look like ^{\circ}C in org file. It works well
> if it is standalone. However, when I put the brackets out of it, say
> (^{\circ}C), the pdf output looks bizarre. I have checked the tex
> output and the converting results from orgmode file are
>
> ^{\circ}C --> $^{\circ}$C
> (^{\circ}C) --> (^\{\circ}C)
Ryan Thompson writes:
> I have found a bug. When the point is at the end of an empty headline
> and you press M-RET (or C-RET) to make a new headline, it deletes all
> the whitespace at the end of the empty headline first, which causes
> the headline to break. I'm not sure if the correct behavior is to
> leave an empty headline, or maybe just do nothing and leave the point
> at the end of the empty headline without creating a new one, but the
> correct thing is definitely *not* to break the headline.
Patch by Jan Bker.
Jan writes:
> What is this?
> =============
>
> This patch changes the way extension regexps in `org-file-apps' are
> handled. Instead of against the file name, the regexps are now matched
> against the whole link, and you can use grouping to extract link
> parameters which you can then use in a command string to be executed.
>
> For example, to allow linking to PDF files using the syntax
> file:/doc.pdf::<page number>, you can add the following entry to
> org-file-apps:
>
> Extension: \.pdf::\([0-9]+\)\'
> Command: evince "%s" -p %1
>
> In a command string to be executed, the parameters can be referenced
> using %1, %2, etc. Lisp forms can access them using (string-match n link).
>
>
> Where to get it?
> ================
> Either apply the patch by hand or
>
> git pull git://github.com/jboecker/org-mode.git org-file-apps-parameters
>
>
> What's next? / Feedback
> =======================
>
> - Find the bugs. Since this messes with links, a central concept of Org,
> I probably have missed some edge cases; so please test this and
> report if it works for you.
>
> I also appreciate any feedback on code quality or the design decisions
> made. I am learning elisp along the way, so you may be able to write
> some changes in a more idiomatic and/or elegant way.
>
> - Add a mechanism for org-mode modules to add default values to
> org-file-apps, similar to the variables org-file-apps-defaults-*.
> This could be used by modules to define their own extensions to the
> syntax of file: links.
>
> - Modify org-docview.el to use this and deprecate the docview: link syntax.
>
>
> What does it (intentionally) break?
> ===================================
>
> This patch introduces a backwards-incompatible change. If LINE or SEARCH
> is given, the file is no longer guaranteed to open in emacs: if IN-EMACS
> is nil and an entry in org-file-apps matches, that takes precedence.
>
> A grep of the lisp/ and contrib/ directories showed that no code in the
> org-mode distribution was relying on this behaviour; whereever LINE or
> SEARCH is given, IN-EMACS is also set to t.
>
> I decided against adding an additional parameter because that would be
> redundant; the original link as seen by org-open-at-point can be
> reconstructed from PATH, LINE and SEARCH.
>
> I am not that sure if this is the right way to do this, but it seems to
> break as little as possible while hopefully avoiding to add too much
> complexity.
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.
Patch by Dan Hackney.
Dan Hackney writes:
> For paragraph text, `org-adaptive-fill-function' did not handle the
> base case of regular text which needed to be filled. This commit saves
> a buffer-local value of `adaptive-fill-regexp' and uses it if none of
> the org-specific regexps match. This allows email-style ">" comments
> to be filled correctly.
org-agenda.el (org-agenda-include-deadlines): Added new
customization variable to determine whether unscheduled tasks
should appear in the agenda solely because of their deadline.
Default to true, which was the previous behavior (it just wasn't
configurable).
(org-agenda-mode-map, org-agenda-view-mode-dispatch): Bind ! in
the agenda to show/hide deadline tasks.
(org-agenda-menu): Added menu option for show/hide deadlines.
(org-agenda-list): Make the agenda list sensitive to the value of
`org-agenda-include-deadlines'.
(org-agenda-toggle-deadlines): New function to toggle the value of
`org-agenda-include-deadlines' and repaint the modeline
indicators.
(org-agenda-set-mode-name): Show "Deadlines" in the agenda
modeline if deadline tasks are being displayed.
Jambunathan K. writes:
> I would like to add the following observation as well -
>
> ---> org input <---
> #+AUTHOR: Jambunathan K\cr\href{mailto:{{{EMAIL}}}}{{{{EMAIL}}}}
>
> ---> actual tex output <---
> \author{Jambunathan K\cr\href{mailto:kjambunathan@gmail.com}\{kjambunathan@gmail.com\}}
>
> The above tex snippet has the effect of getting the "Url Box" wrong.
>
> I was hoping to produce the following line -
> \author{Jambunathan K\cr\href{mailto:kjambunathan@gmail.com}{kjambunathan@gmail.com}}
>
> Generally speaking, macro expansion in author string behaves strangely.
Carsten Dominik
Bastien Guerry
Jan Böcker
Dan Davison
Bernt Hansen
John Wiegley