As the export preprocessor removes indentation from indented blocks,
this causes conflicts about interpreting indentation as list
termination. Now the original indentation is stored in a text
property, so hopefully the exporters can make use of this information
in due time.
All export commands now push the result to the kill ring by default.
This is subject to the variable `org-export-push-to-kill-ring'.
Also, this commit adds a new variable
`org-export-show-temporary-export-buffer' which can be used to turn
off the display of the temporary buffer containing the exported text.
Since this stuff is now automatically pushed onto the kill ring, some
people might prefer not to see this buffer.
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.
Carsten Dominik