Re: [O] [ANN] Org Export in contrib

[Nicolas Goaziou]

Hello,

Carsten Dominik <address@hidden> 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