From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: [ANN] Org Export in contrib Date: Sun, 27 Nov 2011 20:54:57 +0100 Message-ID: <87obvxuyr2.fsf@gmail.com> References: <87ipm8w1jz.fsf@gmail.com> <878vn4vxlh.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([140.186.70.92]:47546) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RUkq4-0000CB-GJ for emacs-orgmode@gnu.org; Sun, 27 Nov 2011 14:56:37 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RUkq3-0002Lu-3w for emacs-orgmode@gnu.org; Sun, 27 Nov 2011 14:56:36 -0500 Received: from mail-bw0-f41.google.com ([209.85.214.41]:61081) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RUkq2-0002Li-RG for emacs-orgmode@gnu.org; Sun, 27 Nov 2011 14:56:35 -0500 Received: by bke17 with SMTP id 17so8313538bke.0 for ; Sun, 27 Nov 2011 11:56:33 -0800 (PST) In-Reply-To: (Carsten Dominik's message of "Sun, 27 Nov 2011 12:21:51 +0100") 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: Carsten Dominik Cc: Org Mode List Hello, Carsten Dominik writes: >> 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. We're not there yet. But I hope there will be no backward compatibility. We really should remove from all export unrelated code the export related text-properties. >> 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? Just put "#+toc: headlines", "#+toc: tables", "#+toc: listings", "#+toc: figures" anywhere in the document (at least with the LaTeX back-end). >> 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? I don't think that macros will be a source of problems since comments and example blocks were weird locations for them anyway. In the LaTeX exporter, "#+index: something" will be transcoded into "\index{something}". That's about it. Should the generic export build a list of all "#+index:" values and store it in a `:index' property (accessible through the communication channel)? >> 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. > 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.... Ok. If anyone can look at it and determine the right thing to do, I will merge it into the exporter code. >> 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. TeX is still supported as a "latex-fragment". In the long run, though, I think TeX commands that are not meant for dvipng/mathjax should be called through an export snippet (that is "@l{...}" temporary syntax). >> 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? There is no defvaralias. Though, I don't mind adding them. Regards, -- Nicolas Goaziou