There is now a new export function, `org-export-as-org', which
basically creates a copy of the Org file with things like archived
trees, commented trees, and trees deselected by export tags,
stripped.
This commit adds:
{{{date(FORMAT)}}} current date/time, formatted with
`format-time-string'
{{{modification-time(FORMAT)}}} date/time of last modification of
file, formatted with `format-time-string'
{{{input-file}}} the file name of the source Org file.
Shaun Johanson writes:
> Consider the following Org file:
>
> * Test
>
> See [[(foo)][FOOBIE]]
>
> #+BEGIN_EXAMPLE
> <foo>: blah blah (ref:foo)
> #+END_EXAMPLE
>
> Question 1)
> In Org mode the link displays as FOOBIE, in the exported HTML it
> displays as (foo). Is there any way to cause the link to use the
> description (FOOBIE) in HTML? If not would this be a useful option
> to add?
This was a bug, fixed now.
Jason Riedy writes:
> I'm trying to change org-export-latex-image-default-option
> to "width=.7\\linewidth" in a file local variable. It's set
> correctly as a buffer local variable, and it's having no
> effect on the export. My guess is that the buffer-local
> property is stopping it as soon as org-export-as-latex runs
> set-buffer.
>
> I can smuggle the value in by adding an entry to org-export-plist-vars
> referring to org-export-latex-image-default-option and pulling the value
> from the plist, but that feels incorrect.
It is actually the correct way to do this, and I have
implemented this change.
Samuel Wales writes:
> I frequently export to ascii without wanting a file to be created,
> especially not in a useful directory, as the files are temporary.
>
> Is there a way to export ascii to just a buffer?
There is now, `C-c C-e A'.
This commit also implements commands
- org-export-as-ascii-to-buffer
- org-replace-region-by-ascii
- org-export-region-as-ascii
which are similar to what is available for HTML and LaTeX.
`C-c C-e A' used to be the key for publishing all projects.
This functionality has now been moved to `C-c C-e E'.
Chris Gray had the idea to have arbitrary blocks turned in LaTeX
environments and HTML divs. These three new hooks allow
implementation has an add-on rather than a patch.
Thomas Morgan writes:
> I just tried exporting an Org file with LaTeX fragments to HTML
> on a computer that doesn't have dvipng. There were error messages
> in *Messages* ("Failed to create png file..."), but this wasn't
> obvious to me at first glance because those messages were replaced
> in the echo area by "Exporting... done" before I could see them.
>
> So I was wondering, is there a good way to make the user aware of
> those errors? Maybe by printing "Exporting... done (with errors)"?
There is now a better error message when either the latex or the
dvipng program does not exist.
Matt Lundin writes:
> If it's not too much trouble, I was wondering if I could
> request the following properties to set export options for
> subtrees:
>
> EXPORT_AUTHOR
> EXPORT_DATE
>
> In addition to specifying an EXPORT_FILE and EXPORT_TITLE
> for a subtree, I often find myself wanting to change the
> date and author lines.
Users can now define custom IDs for use in HTML export.
These IDs are stores as property CUSTOM_ID. When present, HTML will
prefer using these over automatic targets like "sec-N.M".
Some of the standard export options are now defined in backend
specific files. This commit makes sure that building the options
property list will not cause an error because of unneeded (for the
backend) undefined variables.
When exporting to a temporary buffer, images to replace LaTeX
fragments cannot be produced, because there is no useful location
where they can be put. Therefore, these images are not produced in
this case.
In verse environments, line breaks are now enforced both in LaTeX and
in HTML. Centering is now implemented using a div rather than a
paragraph, so that there may be several paragraphs in the centering
environment. Blockquotes now also may have several paragraphs.
If a link is [[#name][desc]], the href wil be exacty href="#name".
So starting a link target with # will indicate that there will be an
explicit target for this.
Hsiu-Khuern Tang writes:
> If I export the file
>
> --------------------------------------------------
> #+OPTIONS: ^:{}
>
> * test
>
> a_{\alpha}
>
> a_{foo}
> --------------------------------------------------
>
> as HTML, I get "a_{α}" but "a<sub>foo</sub>": \alpha is not
> subscripted but foo is. I was expecting both to be subscripted,
> since they are in {}.
This is a bug, fixed now.
Carsten Dominik