Re: [new exporter] [html] Tables of Contents

[tftorrey@tftorrey.com (T.F. Torrey)]

Hello Nicolas,

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> Hello,
>
> tftorrey@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