From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Eric Schulte" Subject: Re: modular block exportation was patch [Feature Addition] exporting comments on org files to html Date: Fri, 07 Nov 2008 11:02:36 -0800 Message-ID: <878wrvwe9f.fsf_-_@gmail.com> References: <87wsfihdjr.fsf@gmail.com> <9AF18490-D824-4083-90A0-F616E213DB89@uva.nl> <87wsfgccv6.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KyWbE-0005di-OG for emacs-orgmode@gnu.org; Fri, 07 Nov 2008 14:02:28 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KyWbD-0005cJ-OG for emacs-orgmode@gnu.org; Fri, 07 Nov 2008 14:02:28 -0500 Received: from [199.232.76.173] (port=52330 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KyWbD-0005bp-LL for emacs-orgmode@gnu.org; Fri, 07 Nov 2008 14:02:27 -0500 Received: from rv-out-0708.google.com ([209.85.198.244]:10024) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KyWbC-0005tc-My for emacs-orgmode@gnu.org; Fri, 07 Nov 2008 14:02:27 -0500 Received: by rv-out-0708.google.com with SMTP id k29so1451886rvb.6 for ; Fri, 07 Nov 2008 11:02:24 -0800 (PST) In-Reply-To: <87wsfgccv6.fsf@gmail.com> (Eric Schulte's message of "Thu, 06 Nov 2008 21:40:45 -0800") 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: Carsten Dominik Cc: Org-mode 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