Hello,

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.

However, I think the new exporter introduces disparities in the output
options that give us a chance to do something better.

In the new exporter, the type of generated Table of Contents depends on
two different configurations:

1. In the #+OPTIONS line, the toc: option determines whether to include
a TOC at the beginning, and how many levels /any/ TOC's should have.

2. The keyword #+TOC: can also be used to insert a generated TOC at a
specific location in the document.  This keyword allows options of
headlines, images, and listings, but it has no provision for levels.

Currently, using the OPTION toc:nil suppresses a default TOC.  Later on,
the #+TOC keyword is still recognized and acted upon, which I think is
the correct behavior, but then it includes all levels in the generated
TOC, because there no way to tell it otherwise.

IMHO, the #+OPTIONS line toc: option is unnecessary.  However, if used,
it should only provide the document default options for generated TOC's.

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

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.)

I don't know how the current options (or these I've proposed) could be
designated in the OPTIONS line.  If we dropped support for the toc:
option in the OPTIONS line, people would have to insert the #+TOC:
keyword with its options where they wanted it.  Would that be so bad?

I was going to post a bug report saying that the initial generated TOC
should not be included if there was a following #+TOC line, but then I
couldn't answer what to do if the later TOC was only images or listings.
My proposal eliminates this problem.

All the best,
Terry
-- 
T.F. Torrey

Reply via email to