Hello Nicolas, Nicolas Goaziou <n.goaz...@gmail.com> writes:
> Hello, > > tftor...@tftorrey.com (T.F. Torrey) writes: > >> The new exporter currently puts the generated Table of Contents at the >> beginning of the exported document in addition to the location of >> "#+TOC: headlines". I don't think it should insert it at the beginning >> when it is called later. > > I think it should. There's no reason for it to go against user's will, > is there? With the old exporter, the OPTIONS toc: option controlled whether a TOC was generated at all. With toc:2 (for instance), if you had "[TABLE-OF-CONTENTS]" somewhere in the document, it would put the TOC there *instead* of at the top. I favor the new behavior. IIUC, your response means that what I proposed is already, mostly, the way things are intended: that the OPTIONS: toc: directive already only applies to the default settings and the TOC at the top. One small problem, though: I see that if there is a TOC at the top and then one included later using #+TOC, the exporter gives them both the same id (<div id="table-of-contents">). Duplicate ID's makes the XML invalid. >> However, I think the new exporter introduces disparities in the output [... 10 lines omitted ...] >> headlines, images, and listings, but it has no provision for levels. > > Of course it has: > > #+TOC: headlines 2 > > It is documented in the manual. I didn't realize that this had been updated. Thanks for the info. [... 15 lines omitted ...] >> Instead, the #+TOC keyword should be changed to support the plist >> structure that has been adopted elsewhere. Thus, an example might be: >> >> #+TOC: :type headlines :levels 2 > > Indeed. I have to change this. But I need to modify the parser for such > attributes first. I'm sure there is no hurry. >> Other options might be included, too, such as the option to suppress >> dates or TODO states as Carsten requested, or perhaps even user-supplied >> options, something like this: >> >> #+TOC: :type headlines :levels 2 :dates nil :todo nil :title nil >> :extra-function my-custom-toc-headline-processor >> >> (In this example, the :title property means the "Table of Contents" at >> the top of the TOC, not the title of the headline.) > > Interesting. But that's some additional work for back-end developers. They could ignore what they can't or don't want to use, of course. >> I don't know how the current options (or these I've proposed) could be >> designated in the OPTIONS line. > > Some defcustom could be used. But we're not there yet. This approach seems obtuse and perhaps over-engineered to me, but I'll let it go. The new TOC design solves a thorny problem I had with the old exporter. Thanks a lot! Best regards, Terry -- T.F. Torrey