From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wes Hardaker Subject: Re: Oorg-export-generic.el and emphasize Date: Fri, 14 Jun 2013 05:38:10 -0700 Message-ID: <0ly5acoojx.fsf@wjh.hardakers.net> References: <51B02B25.5020509@laposte.net> <0ly5anqqaq.fsf@wjh.hardakers.net> <87vc5qw4uu.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:57355) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UnTGp-0005FE-8j for emacs-orgmode@gnu.org; Fri, 14 Jun 2013 08:38:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UnTGj-0001FQ-L6 for emacs-orgmode@gnu.org; Fri, 14 Jun 2013 08:38:23 -0400 Received: from mail.hardakers.net ([168.150.236.43]:57186) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UnTGj-0001Ey-Cr for emacs-orgmode@gnu.org; Fri, 14 Jun 2013 08:38:17 -0400 In-Reply-To: <87vc5qw4uu.fsf@gmail.com> (Nicolas Goaziou's message of "Fri, 07 Jun 2013 13:13:45 +0200") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Nicolas Goaziou Cc: celano , "emacs-orgmode@gnu.org" Nicolas Goaziou writes: > "ox.el" is a generic exporter. I think we should focus on developing > export back-ends for this one instead. > > What feature from `org-export-generic' do you think is missing in > ox.el? ox.el is a wonderfully designed parser and exporter (from what I've read of code, not actually used it (yet)). And my kudos to that and the suite of exporters that go with it! org-export-generic had an entirely different audience in mind, though: the non-programmer. It was designed so that you didn't have to write a function to make it work, and thus was less sophisticated in what it could do. However, with very little effort you could get the output of your choice by simply adding strings to a list and off you go. EG, the configuration was simply a list: ; ... :body-section-header-prefix ("

" "

" "

" "

" "

" "
") :body-section-header-format "%s" :body-section-header-suffix ("
\n" "\n" "\n" "\n" "\n" "\n") :body-text-prefix "

\n" :body-text-suffix "

\n" ; ... So the goal was simply to define a list of tags that would be placed before and after a section. This meant you couldn't do anything complex, but it was very simple to get something running without having to write a single defun. ox.el is different, and much more powerful. You have to write a defun in order to get it to work, but the defuns are generally simple in themselves. What I'd like to have done is either: 1) Rewrite the generic exporter to make use of the ox backend (write a function for each export requirement that looks up the appropriate symbol in the above looking assoc array) 2) Add similar functionality to ox itself so you could set either a function or a string within the org-export-define-backend call. Then the exporter could simply test if it was a simple string or a symbol and react appropriately. -- Wes Hardaker My Pictures: http://capturedonearth.com/ My Thoughts: http://pontifications.hardakers.net/