From: tftorrey@tftorrey.com (T.F. Torrey)
To: emacs-orgmode@gnu.org
Subject: [new exporter] [html] Tables of Contents
Date: Mon, 04 Mar 2013 12:57:28 -0700 [thread overview]
Message-ID: <878v630wgn.fsf@lapcat.tftorrey.com> (raw)
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
next reply other threads:[~2013-03-04 19:59 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-04 19:57 T.F. Torrey [this message]
2013-03-04 20:30 ` [new exporter] [html] Tables of Contents Nicolas Goaziou
2013-03-04 23:10 ` T.F. Torrey
2013-03-05 7:53 ` Nicolas Goaziou
2013-03-05 20:21 ` T.F. Torrey
2013-03-06 4:17 ` Jambunathan K
2013-03-06 4:36 ` Jambunathan K
2013-03-06 12:04 ` Jambunathan K
2013-03-06 21:37 ` T.F. Torrey
2013-03-07 7:57 ` Jambunathan K
2013-03-06 9:51 ` T.F. Torrey
2013-03-06 10:10 ` Jambunathan K
2013-03-06 20:59 ` T.F. Torrey
2013-03-06 22:42 ` Bastien
2013-03-07 0:27 ` Jambunathan K
2013-03-07 9:10 ` Bastien
2013-03-07 9:24 ` Jambunathan K
2013-03-10 5:20 ` Samuel Wales
2013-03-10 5:42 ` Jambunathan K
2013-03-10 9:35 ` Bastien
2013-03-07 0:33 ` Jambunathan K
2013-03-06 10:35 ` Jambunathan K
2013-03-06 21:21 ` T.F. Torrey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=878v630wgn.fsf@lapcat.tftorrey.com \
--to=tftorrey@tftorrey.com \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).