From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carsten Dominik Subject: Re: DocBook exporter code (version 1.0) Date: Sun, 8 Mar 2009 14:46:46 +0100 Message-ID: References: <52A4D4D6-E4BB-4ACF-9438-EB69E71ABEA8@uva.nl> Mime-Version: 1.0 (Apple Message framework v930.3) Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LgJL8-0008Rz-QR for emacs-orgmode@gnu.org; Sun, 08 Mar 2009 09:46:50 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LgJL7-0008Rn-8i for emacs-orgmode@gnu.org; Sun, 08 Mar 2009 09:46:50 -0400 Received: from [199.232.76.173] (port=51524 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LgJL7-0008Rk-4U for emacs-orgmode@gnu.org; Sun, 08 Mar 2009 09:46:49 -0400 Received: from mail-ew0-f179.google.com ([209.85.219.179]:59556) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LgJL6-0006Nu-FB for emacs-orgmode@gnu.org; Sun, 08 Mar 2009 09:46:48 -0400 Received: by ewy27 with SMTP id 27so699883ewy.42 for ; Sun, 08 Mar 2009 06:46:48 -0700 (PDT) In-Reply-To: List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Alex Ott Cc: emacs-orgmode@gnu.org 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