emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Orgmode] modular block exportation was patch [Feature Addition] exp


From: Carsten Dominik
Subject: Re: [Orgmode] modular block exportation was patch [Feature Addition] exporting comments on org files to html
Date: Wed, 12 Nov 2008 07:50:26 +0100


On Nov 12, 2008, at 3:03 AM, Eric Schulte wrote:

Carsten Dominik <address@hidden> writes:

Hi Eric,

I think this interesting functionality could at least initially
be implemented as a add-on, hooking into `org-export-preprocess- hook'. This hook is called before Org looks at any of the blocks, so the hook
could remove blocks or format them and replace them with finished
HTML (in the case of HTML export....) in a BEGIN_HTML ... END_HTML
block.


Hi Carsten,

Thanks for the pointer.  I was able to implement generic block
pre-processing on export using the `org-export-preprocess-hook' you
mentioned.  The resulting org-mode add-on is hosted at

http://github.com/eschulte/org-contrib/tree/master/org-exp-blocks.el

Currently it implements the comment processing I was after, and ditaa
image creation.  I think that it could also be used to implement the
src-code, block-quote, and verse exportation currently implemented in
org-exp.el.

Hi Eric,

since this hook is called early on, you are free to
implement your own processing of other blocks like
example or src as well - maybe in a customizable way, so
that users can opt how they want to do things, of if they
would like to use the formatting built into the Org core.

You might wat to think about the LaTeX side as
well - certainly the ditaa thing could be implemented
for the LaTeX backend - for the ASCII backend it would be
trivial :-)

Thanks for yet another great contribution.

- Carsten



Thanks for the advice, I think this is much better than my initial
comment exportation utility. -- Eric


- Carsten


On Nov 7, 2008, at 8:02 PM, Eric Schulte wrote:

Hi,

This has had me thinking about the exportation of blocks in general.
I
think it makes sense to pull block exportation out into it's own
component both for simplicity and for ease of code-reading, hacking,
and
customization.

with a set of blocks of forms like...

#+begin_html

#+begin_src

#+begin_comment

#+begin_example

etc...

We could have an alist in which we look up the type of the block, and call the appropriate function to handle exportation. Users could then
add their own custom block export functions to this list.

The optional exportation of these blocks could then be controlled by a
single #+option variable which takes a list of blocks not to export.
For example

#+OPTION   hidden_blocks:comment,src

I'd be interested to hear anyone's thoughts on this.  If it sounds
like
a good idea I'd be happy to take a stab at implementation.

Cheers -- Eric





reply via email to

[Prev in Thread] Current Thread [Next in Thread]