From mboxrd@z Thu Jan 1 00:00:00 1970 From: tftorrey@tftorrey.com (T.F. Torrey) Subject: Re: [new exporter] [html] Tables of Contents Date: Mon, 04 Mar 2013 16:10:12 -0700 Message-ID: <87wqtmzrqj.fsf@lapcat.tftorrey.com> References: <87fw0avreq.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([208.118.235.92]:53790) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UCeWo-0005sN-Rr for emacs-orgmode@gnu.org; Mon, 04 Mar 2013 18:10:44 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UCeWn-0005Ur-8D for emacs-orgmode@gnu.org; Mon, 04 Mar 2013 18:10:42 -0500 Received: from relay4-d.mail.gandi.net ([217.70.183.196]:44129) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UCeWn-0005Uh-0y for emacs-orgmode@gnu.org; Mon, 04 Mar 2013 18:10:41 -0500 In-Reply-To: <87fw0avreq.fsf@gmail.com> (message from Nicolas Goaziou on Mon, 04 Mar 2013 21:30:53 +0100) 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: Nicolas Goaziou Cc: emacs-orgmode@gnu.org Hello Nicolas, Nicolas Goaziou 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 (
). 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