From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carsten Dominik Subject: Re: [ANN] Org Export in contrib Date: Mon, 28 Nov 2011 12:40:20 +0100 Message-ID: References: <87ipm8w1jz.fsf@gmail.com> <878vn4vxlh.fsf@gmail.com> <87obvxuyr2.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]:54354) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RUzZV-0003sb-Ll for emacs-orgmode@gnu.org; Mon, 28 Nov 2011 06:40:30 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RUzZU-0006kc-Cv for emacs-orgmode@gnu.org; Mon, 28 Nov 2011 06:40:29 -0500 Received: from mail-ww0-f49.google.com ([74.125.82.49]:34146) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RUzZT-0006kR-UI for emacs-orgmode@gnu.org; Mon, 28 Nov 2011 06:40:28 -0500 Received: by wwf25 with SMTP id 25so1744756wwf.30 for ; Mon, 28 Nov 2011 03:40:26 -0800 (PST) In-Reply-To: <87obvxuyr2.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 On Nov 27, 2011, at 8:54 PM, Nicolas Goaziou wrote: > 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. Yes, I agree. > >>> 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). OK, thanks. > >>> 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)? Yes, I think so! > >>> 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. I will try to look at this possibility. Cheers - Carsten > >>> 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 - Carsten