From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carsten Dominik Subject: Re: [ANN] Org Export in contrib Date: Sun, 27 Nov 2011 12:21:51 +0100 Message-ID: References: <87ipm8w1jz.fsf@gmail.com> <878vn4vxlh.fsf@gmail.com> Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-path: Received: from eggs.gnu.org ([140.186.70.92]:38153) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RUco1-0006Nr-Vd for emacs-orgmode@gnu.org; Sun, 27 Nov 2011 06:21:58 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RUco0-0002FB-Hm for emacs-orgmode@gnu.org; Sun, 27 Nov 2011 06:21:57 -0500 Received: from mail-ww0-f49.google.com ([74.125.82.49]:50221) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RUco0-0002F7-6R for emacs-orgmode@gnu.org; Sun, 27 Nov 2011 06:21:56 -0500 Received: by wwf5 with SMTP id 5so5471520wwf.30 for ; Sun, 27 Nov 2011 03:21:55 -0800 (PST) In-Reply-To: <878vn4vxlh.fsf@gmail.com> 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: Org Mode List Hi Nicolas, a few comments: On 25.11.2011, at 19:57, Nicolas Goaziou wrote: > > Completing myself, I'll add a few notes about the differences between > the current exporter and this one. While it tries to mimic most of the > behaviours of its ancestor, some points just couldn't fit in the new > scheme, would it be for a technical reason or by design. > > Here follows a rough list stating how the new engine stands with regards > to the older one. When possible, the reasons justifying that the > difference remains are given. > > 1. It's slower. Indeed, it has to first parse completely the area to > transcode, even if it doesn't transcode it after (i.e. archive > trees). It's the job of the exporter to decide what should or > shouldn't be exported. Anticipating filtering would be disastrous > for some exporters (i.e. the Org one) and wouldn't fit the modular > design. I am curious to see how slow it will be. If necessary, export can be pushed to a background process, but I do not think this will be necessary. > 2. The document title cannot be obtained anymore from the first line of > text. It's either explicitely defined with the =TITLE= keyword, or > derived from buffer's name. This is actually good, I think. Much of the stuff like initial text, title from text etc are leftovers from early time. It might mean that we will have to keep the old exporters around somewhere, if someone needs compatibility. > > 3. =TEXT= keywords at the beginning of the document are unneeded, and, > as such, no longer have an effect. > > 4. "[TABLE OF CONTENTS]" as a placeholder for the table of contents has > been removed. Though, a new keyword, =TOC=, achieves the same > effect, and can even take more values, like "contents", "tables", > "figures" and "listings". Tools are provided to make them available > to any exporter to come. What do you mean by "keyword"? Can you provide an example of how to place the TOC? > > 5. "-t" option at a src or example block isn't supported anymore. This > is an HTML only option that could fit in =attr_html= affiliated > keyword instead, with a "textarea" value. A new HTML back-end isn't > available yet, but should develop in that direction anyway. Yes, this is a good alternative. > > 6. Macros have been under powered a little. They cannot live anymore in > comments, example blocks, or even src blocks. In fact, one cannot > find a macro where the text isn't parsed. Macros are Org syntax. > Using such syntax where there is, by definition, none is just > nonsensical. I know that Stefan Vollmar is using macros in complicated and extensive ways. I also know that he is using the index facilities, which so far have depended heavily on the preprocessor. I am curious how indexing will work with org-elements. Have you put any thought into this? > > 7. For the same reason, invisible targets in comments have been > deprecated. For the same result, one can now use a =TARGET= keyword > instead. This is actually better... > > 8. =INCLUDE= keyword :prefix, :prefix1 and :minlevel properties support > has been dropped. Though, the keyword, which doesn't have to be at > column 0 anymore, is aware about its environment. If it belongs to > a list, the whole file will be in the current item. Also, including > a file from within a sub-tree will always make the top-level headline > of the included file is a direct child of that sub-tree. One > technical drawback is that no Babel block is executed in the included > file. Again, no loss, this was a weird feature anyway. > > 9. Table.el tables will always use their own export back-end. In other > words, no Org syntax will be recognized in such table anymore. > A table.el is an extraneous element while the parser is meant to > parse Org syntax. Now, an interesting idea from /Jambunathan K./, > namely his "list-tables", might fill the gap between the Org > spreadsheet and the table.el table. Nothing is implemented about it > right now, but we're talking about a modular and extensible parser, > after all. Maybe we should see if there is a hook in table.el which could be called to format text in a backend specific way. If it is not there, maybe we can simply introduce it ourselves, or add some advice for this purpose.... > > 10. Calling an export function with a numeric argument doesn't change > headline maximum level, by default. There are enough ways to change > this export property already and the argument may be required for > something more important in the future. Again, less is more. > > 11. =org-export-with-TeX-macros= has been replaced with the more > appropriate =org-export-with-entities=, and the associated =OPTIONS= > keyword's symbol changed from =TeX:nil= to =e:nil=. I do like the change, but maybe it would be good to support TeX for backward compatibility... Then, maybe, we are breaking a few things anyway. > > 12. About variables changes, =org-export-author-info=, > =org-export-creator-info= and =org-export-email-info= have been > replaced with, respectively, =org-export-with-author=, > =org-export-with-creator= ad =org-export-with-email=, for the sake > of consistency with other opt-in variables. Are you adding defvaralias for compatibility, or are you arguing for a clean break here? Regards - Carsten