Re: [ANN] Org Export in contrib

[Carsten Dominik <carsten.dominik@gmail.com>]

On Nov 27, 2011, at 8:54 PM, Nicolas Goaziou wrote:

> Hello,
> 
> Carsten Dominik <carsten.dominik@gmail.com> 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