* lisp/org-agenda.el (org-agenda-get-sexps): Handle lists as return values
from diary entries
* lisp/org-bbdb.el (org-bbdb-anniversaries): Handle lists of anniversaries
* lisp/org.el (org-diary-sexp-entry): Handle lists as return values
from diary entries.
ukasz Stelmach <lukasz.stelmach@iem.pw.edu.pl> writes:
> I've disovered, that %%(org-bbdb-anniversaries) returns (as every other
> sexp) a string. Which is OK if there is only one.
>
> Anniversaries: John Doe's 10th wedding anniversary
>
> Unfortunately the agenda view becomes awful if we have noted Jane's
> weeding date too
>
> Anniversaries: John Doe's 10th wedding anniversary; Jane Doe's 10th wedding anniversary
>
> And what if we know 3 Eves and 5 Adams and it's Christmas Eve? (Hint:
> their name day)
[...]
As Thomas Bauman pointed out, there are functions that can be used in
sexps which return cons cells like this
(nil . "Full Moon 3:35am (CEST)")
(this one is diary-lunar-phases), these aren't properly supported by the
previous version of my patch. This one can distinguish between such a
cons cell and a "real" list.
("John Doe's 10th wedding anniversary"
"Jane Doe's 10th wedding anniversary")
This is because
(consp (cdr '(a . b))) ; => nil
so org-diary-sexp-entry can be made return (cdr result) only in case of
the former cons cell. The third condition in the `cond' block is IMHO
enough as it is now, but if you think adding
(listp (cdr result))
may help then be it.
* lisp/org-capture.el (org-capture-empty-lines-before):
(org-capture-empty-lines-after): Make sure the n=0 does not insert any
newlines.
Marcel van der Boom writes:
> I'm in the process of migrating from org-remember to org-capture.
> Pretty easy going so far, but it seems org-capture adds newlines, which
> I think it should not do.
>
> My (test) capture-template is:
>
> (("t" "Todo" entry
> (file "~/.outlet/GTD.org")
> "* TODO %?" :prepend t :empty-lines 0)
>
> with the intention of inserting the captured task on the
> first line of the file ~/.outlet/GTD.org. What happens when I capture
> an task is this:
>
> <beginning of file>
>
> * TODO Captured task
>
> <original first line of file here>
> ....
>
> Both before and after the task is a newline. Also, when capturing and
> cancelling the capture with C-c C-k the newlines remain whereas the
> task is removed.
* lisp/org-html.el (org-format-table-html): New argument DOCBOOK.
(org-format-org-table-html): New argument DOCBOOK. When set, use
align instead of class to align table fields.
* lisp/org-docbook.el (org-export-as-docbook): Specify the docbook argument
for the table converter.
* lisp/org-macs.el (org-called-interactively-p): New macro.
* lisp/org-freemind.el: No longer require 'rx.
(org-freemind): New customization group, use it for all the variables.
(org-export-as-freemind): Add docstring.
(org-freemind-show): Improve filen naming.
(org-freemind-convert-links-helper): New function.
(org-freemind-bol-helper-base-indent): New variable.
(org-freemind-bol-helper): New function.
(org-freemind-node-css-style): New option.
(org-freemind-node-pattern): New variable.
(org-freemind-from-org-mode): Better docstring.
* lisp/org-footnote.el (org-footnote-create-definition)
(org-footnote-goto-local-insertion-point): Add footnotes before
signature when in message-mode.
* lisp/org.el (org-cycle): Make sure resetting to startup visibility
works after another cycle command.
Gez writes:
> I have a query about the C-u C-u TAB command. When I've just edited
> or used S-TAB (no matter which part of the global cycle it's on) C-u
> C-u TAB works as I would expect. But if I've just used TAB, C-u C-u
> TAB cycles hrough -> CONTENTS -> SHOW ALL etc, even while the mini
> buffer displays "startup visibility plus VISIBILITY properties" at
> each stage of the cycle. C-u C-u TAB also cycles when it's repeated.
> I find it hard to keep track of whether it will cycle or not while I'm
> using it to view areas of the outline, so in effect, the only way I
> feel sure I can quickly return to my desired startup visibility is
> with S-TAB C-u C-u TAB, which is a lot of keystrokes! So my questions
> are - is this expected behaviour? Can it be changed?
The attached patch adds a new functions org-export-string.
,----
| org-export-string is a Lisp function in `org-exp.el'.
|
| (org-export-string STRING FMT &optional DIR)
|
| Export STRING to FMT using existing export facilities.
| During export STRING is saved to a temporary file whose location
| could vary. Optional argument DIR can be used to force the
| directory in which the temporary file is created during export
| which can be useful for resolving relative paths. Dir defaults
| to the value of `temporary-file-directory'.
`----
This function should be useful in user code, and can already reduce the
amount of code in ob-org.el and org-mime.el.
>From e51017e4d7051aad31384a470f0a695dca0d6716 Mon Sep 17 00:00:00 2001
From: Eric Schulte <schulte.eric@gmail.com>
Date: Sun, 17 Oct 2010 15:17:13 -0600
Subject: [PATCH] org-export-string -- exports a string of org-mode markup text
* lisp/org-exp.el (org-export-string): new function org-export-string
can be used to convert a string of test in org-mode markup to a
specified format
* contrib/lisp/org-mime.el (org-mime-htmlize): now using new
org-export-string function for exportation
* lisp/ob-org.el (org-babel-execute:org): now using new
org-export-string function for exportation
* doc/org.texi: Document the <c> cookie.
* lisp/org-exp.el (org-store-forced-table-alignment):
(org-export-remove-special-table-lines): Allow the "c" cookie for
table alignment.
* lisp/org-html.el (org-export-table-header-tags):
(org-export-table-data-tags): Add another %s format for the alignment.
(org-export-html-table-align-individual-fields): New option.
(org-format-org-table-html): Implement field-by-field alignment and
support centering.
(org-format-table-table-html): Make sure the new table tag formats
don't break this function.
* lisp/org-table.el (org-table-cookie-line-p):
(org-table-align): Allow for the <c> cookie.
* lisp/org.el (org-set-font-lock-defaults): Allow for the <c> cookie.
* lisp/org-indent.el: (org-indent-add-properties): Use
`with-silent-modificaitons'.
(org-indent-remove-properties): Use `with-silent-modificaitons'.
Julien Danjou writes:
> I'm using org 7.01h with Emacs 24 trunk. When I set org-startup-indented
> to t, I observe the following:
>
> ** TODO Some stuff
>
> I select "stuff" and press M-w. Then I go the the line under and press
> C-y (org-yank).
>
> Now I got:
>
> ** TODO Some stuff
> ** TODO Some
>
> instead of:
>
> ** TODO Some stuff
> stuff
>
> Note that after M-w, `kill-ring' has a correct first entry of "stuff":
>
> (#("stuff" 0 5
> (fontified t face org-level-2))
> ...)
>
> But on C-y (org-yank) something happens, and it paste the wrong text. I
> think it's trying to be smart but it's not.
>
> I've found that setting org-startup-indented to nil fix that behaviour.
* ob-sh.el (org-babel-sh-var-to-sh): Ensure value has the
structure of an Org-mode table (list of lists)
Non-nested lists can arise either by explicit assignment,
e.g. :var '(1 2), or by assigning a one-dimensional slice of a table.
* lisp/ob-tangle.el (org-babel-tangle-collect-blocks): now explicitly
checks that a code block will actually be tangled before collecting
it's full information (a process which could involve the execution
of other code blocks)
* lisp/ob.el (org-babel-sha1-hash): now handles more complex types in
params
* testing/examples/babel.org: whitespace
* testing/lisp/test-ob.el (test-org-babel/sha1-hash): new test for
babel hashing
* lisp/ob.el (org-babel-execute-src-block): generally using the new
more informative params
(org-babel-process-params): don't forget the :var portion of
variable assignments
Łukasz Stelmach
Carsten Dominik
Eric Schulte
David Maus
Jambunathan K
Daniel Clemente
Tassilo Horn
Noorul Islam
Dan Davison