Allow C-2 C-c C-w to work in the agenda.
Update agenda after refiling
This rebuilds the agenda buffer after the refile operation completes.
It was removing the to-be-refiled task before prompting for the location
which felt a little strange. While on the prompt you can't see
the task you are refiling anymore since it was just removed from the
agenda list and if you aborted from the refile operation
with C-g then the task to be refiled has already been removed.
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.
Previously "R" could overshadow "Ruby", and "C" could overshadow
"Clojure", causing blocks of the longer language name to fail to
load. This issue has now been fixed
thanks to Maurizio Vitale for the suggestion. This allows literal
values to be passed to code blocks through `sbe' without forcing the
use of quotes inside the table.
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.
Carsten Dominik
Bernt Hansen
Eric Schulte
Dan Davison