From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carsten Dominik Subject: Re: modular block exportation was patch [Feature Addition] exporting comments on org files to html Date: Wed, 12 Nov 2008 07:50:26 +0100 Message-ID: References: <87wsfihdjr.fsf@gmail.com> <9AF18490-D824-4083-90A0-F616E213DB89@uva.nl> <87wsfgccv6.fsf@gmail.com> <878wrvwe9f.fsf_-_@gmail.com> <026208AB-35E7-4D5B-8EFB-FCD2B31AFAB3@uva.nl> <873ahxsntl.fsf@gmail.com> Mime-Version: 1.0 (Apple Message framework v929.2) 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 1L09Yg-0006YM-5l for emacs-orgmode@gnu.org; Wed, 12 Nov 2008 01:50:34 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L09Ye-0006Xm-Ge for emacs-orgmode@gnu.org; Wed, 12 Nov 2008 01:50:33 -0500 Received: from [199.232.76.173] (port=41037 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L09Ye-0006Xd-7E for emacs-orgmode@gnu.org; Wed, 12 Nov 2008 01:50:32 -0500 Received: from ey-out-1920.google.com ([74.125.78.144]:63703) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1L09Yc-0000yX-QG for emacs-orgmode@gnu.org; Wed, 12 Nov 2008 01:50:31 -0500 Received: by ey-out-1920.google.com with SMTP id 4so112871eyg.24 for ; Tue, 11 Nov 2008 22:50:29 -0800 (PST) In-Reply-To: <873ahxsntl.fsf@gmail.com> 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: Eric Schulte Cc: Org-mode On Nov 12, 2008, at 3:03 AM, Eric Schulte wrote: > Carsten Dominik 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