all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Nicolas Goaziou <n.goaziou@gmail.com>
To: "T.F. Torrey" <tftorrey@tftorrey.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: [new exporter] [html] Tables of Contents
Date: Mon, 04 Mar 2013 21:30:53 +0100	[thread overview]
Message-ID: <87fw0avreq.fsf@gmail.com> (raw)
In-Reply-To: <878v630wgn.fsf@lapcat.tftorrey.com> (T. F. Torrey's message of "Mon, 04 Mar 2013 12:57:28 -0700")

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?

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

Of course it has:

  #+TOC: headlines 2

It is documented in the manual.

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

See above.

> IMHO, the #+OPTIONS line toc: option is unnecessary.

If you remove it, you have no way to insert a table of contents in the
header anymore. It may be important for some back-ends.

> 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

Indeed. I have to change this. But I need to modify the parser for such
attributes first.

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

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

> 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?

Yes, see above.


Regards,

-- 
Nicolas Goaziou

  reply	other threads:[~2013-03-04 20:31 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 [this message]
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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87fw0avreq.fsf@gmail.com \
    --to=n.goaziou@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=tftorrey@tftorrey.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 external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.