Stefan Vollmar writes:
> taking up a nice suggestion from Sebastian Rose, I want to
> present some org source with proper syntax highlighting. However,
> there is a problem when using "BEGIN_SRC" blocks it seems.
>
> If one puts this org contents into a file "test.org":
>
> * One Headline
> Some Text
> #+BEGIN_SRC python
> print "some output"
> #+END_SRC
> * Another headline
> More text
>
> and renders it from another org-file with:
>
> #+INCLUDE: "./test.org" src org
>
> everything will be fine (beautiful, infact) up to and including
> the print-line - the rest of the org file is not rendered as
> source but interpreted.
This commit adds a new hook `org-src-mode-hook'.
The Hook run after Org switched a source code snippet to
its Emacs mode. This hook will run
- when editing a source code snippet with \"C-c '\".
- When formatting a source code snippet for export with htmlize.
You may want to use this hook for example to turn off `outline-minor-mode'
or similar things which you want to have when editing a source code file,
but which mess up the display of a snippet in Org exported files.
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.
Carsten Dominik