From: tftorrey@tftorrey.com (T.F. Torrey)
To: Nicolas Goaziou <n.goaziou@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: [new exporter] [html] Tables of Contents
Date: Mon, 04 Mar 2013 16:10:12 -0700 [thread overview]
Message-ID: <87wqtmzrqj.fsf@lapcat.tftorrey.com> (raw)
In-Reply-To: <87fw0avreq.fsf@gmail.com> (message from Nicolas Goaziou on Mon, 04 Mar 2013 21:30:53 +0100)
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
next prev parent reply other threads:[~2013-03-04 23:10 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-04 19:57 [new exporter] [html] Tables of Contents T.F. Torrey
2013-03-04 20:30 ` Nicolas Goaziou
2013-03-04 23:10 ` T.F. Torrey [this message]
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=87wqtmzrqj.fsf@lapcat.tftorrey.com \
--to=tftorrey@tftorrey.com \
--cc=emacs-orgmode@gnu.org \
--cc=n.goaziou@gmail.com \
/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).