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.
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.
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.
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.
John Wiegley writes:
> I have the following data in my Org-mode file:
>
> #+LINK: cegbug https://portal/bugzilla/show_bug.cgi?id=
>
> ** TODO [[cegbug:351][#351]] Bizcard: Fix Maven build setup
> - State "TODO" from "STARTED" [2010-03-01 Mon 14:42]
>
> Now, in the Agenda and in the Org-mode buffer, everything looks fine.
> I can also use C-c C-o if my cursor is within the #<NUMBER> text.
>
> However, if I'm in the Agenda and I hit C-c C-o, it says 'No match'
> after about a second. Is there any reason I can't open these links
> from the Agenda view?
This support was totally broken. It works now again. Unfortunately
it is not possible to edit the table directly in the org-mode buffer
anymore - to edit such a table, you have to use C-c '
This patch implements reading American dates, like
2/5/3 --> 2003-02-05
2/5 --> ????-02-05
Is also fixes a bug that would force the current year when reading a
date like 2/5 (American) or 2-5 (ISO), and in this way would prevent
`org-read-date-prefer-future' to do its job. This bug was reported by
Lukasz Stelmach.
Move the marker for the last refile location to the heading instead of at the
end of the entry. This was causing C-u C-u C-c C-w to end up on the heading
following the newly refiled entry.
This can help to get out of an inconsistent state produce for example
by viewing from the agenda. Reported by Matt Lundin:
> I'd like to report a minor issue with org-agenda-goto and inline tasks.
> Let's say one has the following file:
>
> --8<---------------cut here---------------start------------->8---
> * Here is an entry.
> Blah blah blah blah.
> *************** Here is an inline task.
> *************** END
> Blah blah blah blah blah.
> *************** TODO Here is a second inline task.
> *************** END
> Blah blah blah blah blah.
> *************** Here is a third inline task
> *************** END
> Blah blah blah blah blah.
> --8<---------------cut here---------------end--------------->8---
>
> Let's say one also has the following settings:
>
> --8<---------------cut here---------------start------------->8---
> (setq org-show-hierarchy-above t)
> (setq org-show-siblings '((default . nil) (isearch . t) (agenda . t)))
> (setq org-show-entry-below '((default . nil) (isearch . t) (agenda . t)))
> --8<---------------cut here---------------end--------------->8---
>
> If 1) one tries to jump to the TODO from the agenda and 2) the entry is
> currently folded, org-show-context reveals only the headlines. E.g.,
>
> --8<---------------cut here---------------start------------->8---
> * Here is an entry.
> *************** Here is an inline task.
> *************** END...
> *************** TODO Here is a second inline task.
> *************** END...
> *************** Here is a third inline task
> *************** END...
> --8<---------------cut here---------------end--------------->8---
>
> Invoking org-cycle on the END headline does nothing, since all headlines
> deeper than org-inlinetask-min-level are exempted from cycling. As a
> result, the only way to reveal the text in the entry is to cycle the
> parent twice (first to close, then to reveal).
Carsten Dominik
Bastien Guerry
Dan Davison
Eric Schulte
Bernt Hansen