From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: [new exporter] [html] Tables of Contents Date: Mon, 04 Mar 2013 21:30:53 +0100 Message-ID: <87fw0avreq.fsf@gmail.com> References: <878v630wgn.fsf@lapcat.tftorrey.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([208.118.235.92]:38343) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UCc2Q-0003lB-Cp for emacs-orgmode@gnu.org; Mon, 04 Mar 2013 15:31:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UCc2N-0006oF-AM for emacs-orgmode@gnu.org; Mon, 04 Mar 2013 15:31:10 -0500 Received: from mail-wg0-f46.google.com ([74.125.82.46]:46853) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UCc2N-0006nl-25 for emacs-orgmode@gnu.org; Mon, 04 Mar 2013 15:31:07 -0500 Received: by mail-wg0-f46.google.com with SMTP id fg15so4456453wgb.13 for ; Mon, 04 Mar 2013 12:31:06 -0800 (PST) In-Reply-To: <878v630wgn.fsf@lapcat.tftorrey.com> (T. F. Torrey's message of "Mon, 04 Mar 2013 12:57:28 -0700") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: "T.F. Torrey" Cc: emacs-orgmode@gnu.org 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