[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Orgmode] DocBook exporter code (version 1.0)
From: |
Carsten Dominik |
Subject: |
Re: [Orgmode] DocBook exporter code (version 1.0) |
Date: |
Sun, 8 Mar 2009 14:46:46 +0100 |
On Mar 8, 2009, at 10:43 AM, Alex Ott wrote:
Hello
"CD" == Carsten Dominik writes:
....
CD> One of the really weak features in Org's design is that
exporting is
CD> not implemented in a generic way. All exporters share a
preprocessing
CD> step that turns Org format into something a little more sane and
CD> consistent. Then each exporter goes its own way. This setup
makes
CD> maintenance sort of a nightmare, because each change to Org syntax
CD> needs to be implemented in all exporters separately. Maybe you
have
CD> read my swearing when I was trying to fix the LaTeX exporter
which I
CD> did not understand completely at first - it was written by
Bastien.
CD> I had really hoped that the next step in exporting Org would be to
CD> rewrite the exporter from scratch, in a generic way, that will
then
CD> make supporting different formatters more stable and easy.
Adding a
CD> new exporter does not get us closer to that idea.
I think, that instead of parsing text directly, we need to write
generic
exporter, that will export all data as a tree, consisting from
header +
list of the entries, and inside these entries provide all needed
information about text (markup, url information, etc.). And for new
export
format, author will define only small piece of code -- mostly header
generation, and replacement tables for formatting tags, urls
decorations,
etc.
Yes, exactly. This is exactly the right idea. A complete
parser that captures the *entire* structure including all meta data,
without being specific to a backend.
There is a start for such a system in the git repo,
in EXPERIMENTAL/org-export.el, written by Bastien. It does a
pass to get the headline structure of the document, and the properties
as meta data in a property list. I believe it might not
capture TODO state and/or priority, but I am not certain.
The LaTeX exporter is based on this parser, but it is a half-done job
as it does the parsing only for the outline structure, not really
for the content.
There is also a parser for plain lists, in org-list.el, which
is also used in the LaTeX exporter (yes, Bastien had many of the
right ideas).
The is lots of other meta info like targets, links, formatting
information
that would have to be encoded in some way. It might be useful to
start with the
export preprocessor on the entire file and use it. One of the hard
things will
be to identify stuf that is LaTeX, but also this code is in principle
present.
This would be great to achieve. Be warned that it will be hard
to get right, and that you and others would largely have to drive
it. I will help, but cannot do the main thrust - maintaining Org
as it is and adding some features takes most of the energy I can
currently contribute.
- Carsten