doctools::toc::export(n)

πŸ“¦
version 2.0 Β· 2 versions
, in fedora 43, fedora 44, nixos 26.05, nixpkgs unstable

πŸ’– doctools::toc::export β€” from the Documentation tools manual, section (n) πŸ’–

NAME ✨

doctools::toc::export β€” exporting tables of contents πŸŽ€


SYNOPSIS 🌸

package require doctools::toc::export ?0.2.2?

package require Tcl 8.5 9

package require struct::map

package require doctools::toc::structure

package require snit

package require pluginmgr

::doctools::toc::export objectName

objectName method ?arg arg ...?

objectName destroy

objectName export serial serial ?format?

objectName export object object ?format?

objectName config names

objectName config get

objectName config set name ?value?

objectName config unset pattern...

export serial configuration

DESCRIPTION πŸ’«

okay bestie, so this package hands you a class that manages the plugins for exporting tables of contents into other formats β€” as in, converting a ToC into stuff like doctoc, HTML, etc. iconic behaviour, no notes πŸ’…

This is one of the three public pillars that all the table-of-contents management sits on. The other two pillars are:

  1. Importing tables of contents, and
  2. Holding tables of contents

Want the tea on the Concepts of tables of contents and all their little parts? That's the same-named section below πŸ‘‡. And if you wanna know about the data structure that's the major input to the manager objects this package gives you, go read the section ToC serialization format.

The plugin system in our class is built on the package pluginmgr, and it's configured to go looking for plugins using:

  1. the environment variable DOCTOOLS_TOC_EXPORT_PLUGINS,
  2. the environment variable DOCTOOLS_TOC_PLUGINS,
  3. the environment variable DOCTOOLS_PLUGINS,
  4. the path ~/.doctools/toc/export/plugin
  5. the path ~/.doctools/toc/plugin
  6. the path ~/.doctools/plugin
  7. the path ~/.doctools/toc/export/plugins
  8. the path ~/.doctools/toc/plugins
  9. the path ~/.doctools/plugins
  10. the registry entry "HKEY_CURRENT_USER\SOFTWARE\DOCTOOLS\TOC\EXPORT\PLUGINS"
  11. the registry entry "HKEY_CURRENT_USER\SOFTWARE\DOCTOOLS\TOC\PLUGINS"
  12. the registry entry "HKEY_CURRENT_USER\SOFTWARE\DOCTOOLS\PLUGINS"
heads up: those last three are only used when the package is running on a machine with a Windows(tm) operating system. so, like, not your problem on a macbook, bestie πŸ“

The whole system ships with six predefined export plugins, namely:

  • doctoc β€” See doctoc export plugin for details.
  • html β€” See html export plugin for details.
  • json β€” See json export plugin for details.
  • nroff β€” See nroff export plugin for details.
  • text β€” See text export plugin for details.
  • wiki β€” See wiki export plugin for details.

And if you're a reader who wants to write your own export plugin for some format β€” hello, plugin writer, main character energy πŸ‘‘ β€” then reading and actually understanding the section containing the Export plugin API v2 reference is an absolute necessity. it spells out the interaction between this package and its plugins in detail, so like… don't skip it fr fr 😭


CONCEPTS πŸ¦‹

  1. A table of contents consists of a (possibly empty) list of elements.
  2. Each element in the list is identified by its label.
  3. Each element is either a reference, or a division.
  4. Each reference has an associated document, identified by a symbolic id, and a textual description.
  5. Each division may have an associated document, identified by a symbolic id.
  6. Each division consists of a (possibly empty) list of elements, with each element following the rules as specified in item 2 and above.

A few notes πŸ’œ

  1. The above rules span up a tree of elements, with references as the leaf nodes, and divisions as the inner nodes, and each element representing an entry in the whole table of contents.
  2. The identifying labels of any element E are unique within their division (or toc), and the full label of any element E is the list of labels for all nodes on the unique path from the root of the tree to E, including E.

API 🌈

PACKAGE COMMANDS πŸ‘‘

  • ::doctools::toc::export objectName β€” this command creates a brand-new export manager object, and it comes with an associated Tcl command whose name is objectName. That object command gets explained in full detail in the sections Object command and Object methods. The object command gets created under the current namespace if objectName isn't fully qualified, and in the specified namespace otherwise. slay ✨

OBJECT COMMAND πŸŽ€

Every single object created by the ::doctools::toc::export command has this general form:

objectName method ?arg arg ...?
  • The method method and its arg'uments determine the exact behavior of the command. Peep the section Object methods for the detailed specifications.

OBJECT METHODS πŸ’…

  • objectName destroy β€” this method destroys the object it's invoked for. bye bestie πŸ‘‹
  • objectName export serial serial ?format? β€” this method takes the canonical serialization of a table of contents stored in serial and converts it to the specified format, using the export plugin for that format. An error is thrown if no plugin could be found for the format. The string generated by the conversion process gets returned as the result of this method.
    • If no format is specified, the method defaults to doctoc.
    • The specification of what a canonical serialization is can be found in the section ToC serialization format.
    • The plugin has to conform to the interface specified in section Export plugin API v2 reference.
  • objectName export object object ?format? β€” this method is a convenient little wrapper around the export serial method described by the previous item. It expects that object is an object command supporting a serialize method returning the canonical serialization of a table of contents. It invokes that method, feeds the result into export serial, and returns the resulting string as its own result. lowkey genius 🧚
  • objectName config names β€” this method returns a list containing the names of all configuration variables currently known to the object.
  • objectName config get β€” this method returns a dictionary containing the names and values of all configuration variables currently known to the object.
  • objectName config set name ?value? β€” this method sets the configuration variable name to the specified value and returns the new value of the variable.
    • If no value is specified it simply returns the current value, without changing it.
    • > note: while the user can set the predefined configuration variables user and format, doing so will have no effect β€” these values will be internally overridden when invoking an import plugin. so don't waste your time, bestie πŸ™ˆ
  • objectName config unset pattern... β€” this method unsets all configuration variables matching the specified glob patterns. If no pattern is specified it will unset all currently defined configuration variables. gone. deleted. periodt πŸ’€

EXPORT PLUGIN API V2 REFERENCE πŸ”₯

Plugins are what this package uses to manage the support for any output format beyond the ToC serialization format. Here we specify the API that the objects created by this package use to interact with their plugins. iykyk πŸ‘‘

A plugin for this package has to follow the rules listed below:

  1. A plugin is a package.
  2. The name of a plugin package has the form doctools::toc::export::FOO, where FOO is the name of the format the plugin will generate output for. This name is also the argument to provide to the various export methods of export manager objects to get a string encoding a table of contents in that format.
  3. The plugin can expect that the package doctools::toc::export::plugin is present, as indicator that it was invoked from a genuine plugin manager.
  4. A plugin has to provide one command, with the signature shown below.
export serial configuration
  • Whenever an export manager of doctools::toc has to generate output for a table of contents it will invoke this command.
  • string serial β€” this argument will contain the canonical serialization of the table of contents for which to generate the output. The specification of what a canonical serialization is can be found in the section ToC serialization format.
  • dictionary configuration β€” this argument will contain the current configuration to apply to the generation, as a dictionary mapping from variable names to values.
    • The following configuration variables have a predefined meaning all plugins have to obey, although they can ignore this information at their discretion. Any other configuration variables recognized by a plugin will be described in the manpage for that plugin.
    • user β€” this variable is expected to contain the name of the user owning the process invoking the plugin.
    • format β€” this variable is expected to contain the name of the format whose plugin is invoked.
    • file β€” this variable, if defined by the user of the table object, is expected to contain the name of the input file for which the plugin is generating its output for.
    • map β€” this variable, if defined by the user of the table object, is expected to contain a dictionary mapping from symbolic document ids used in the table entries to actual paths (or urls). A plugin has to be able to handle the possibility that a document id is without entry in this mapping. 🫢
  1. A single usage cycle of a plugin consists of the invokations of the command export. This call has to leave the plugin in a state where another usage cycle can be run without problems.

🌈 TOC SERIALIZATION FORMAT 🌈

okay so this is where we spill the tea on the actual format the doctools v2 packages use to serialize tables of contents as immutable values, so they can be shipped around, compared, all that. ✨

we got two flavors here: regular serializations and canonical ones. a table of contents can have more than one regular serialization (she contains multitudes πŸ’…), but exactly one of them is the canonical one. one. singular. iconic.


πŸ’– regular serialization πŸ’–

  1. The serialization of any table of contents is a nested Tcl dictionary. yes bestie, it's dictionaries all the way down 🫢
  2. This dictionary holds a single key, doctools::toc, and its value. That value holds the contents of the table of contents.
  3. The contents of the table of contents are a Tcl dictionary holding the title of the table of contents, a label, and its elements. The relevant keys and their values are
    • title β€” the value is a string containing the title of the table of contents.
    • label β€” the value is a string containing a label for the table of contents.
    • items β€” the value is a Tcl list holding the elements of the table, in the order they are to be shown. πŸ‘‘

Each element is a Tcl list holding the type of the item, and its description, in this order. Another way to think about it: it's a Tcl dictionary holding a single key, the item type, mapped to the item description.

The two legal item types and their descriptions are

  • reference β€” this item describes a single entry in the table of contents, referencing a single document. To this end its value is a Tcl dictionary containing an id for the referenced document, a label, and a longer textual description which can be associated with the entry. The relevant keys and their values are
    • id β€” the value is a string containing the id of the document associated with the entry.
    • label β€” the value is a string containing a label for this entry. This string also identifies the entry, and no two entries (references and divisions) in the containing list are allowed to have the same label. 🚨 no duplicates, we do NOT do that here.
    • desc β€” the value is a string containing a longer description for this entry.
  • division β€” this item describes a group of entries in the table of contents, inducing a hierarchy of entries. so yes, nesting. matryoshka doll energy πŸͺ† To this end its value is a Tcl dictionary containing a label for the group, an optional id to a document for the whole group, and the list of entries in the group. The relevant keys and their values are
    • id β€” the value is a string containing the id of the document associated with the whole group. This key is optional. optional bestie, she can ghost if she wants πŸ’…
    • label β€” the value is a string containing a label for the group. This string also identifies the entry, and no two entries (references and divisions) in the containing list are allowed to have the same label. same rule as before, no cap.
    • items β€” the value is a Tcl list holding the elements of the group, in the order they are to be shown. This list has the same structure as the value for the keyword items used to describe the whole table of contents, see above. And that closes the recursive definition of the structure, with divisions holding the same type of elements as the whole table of contents, including other divisions. πŸŒ€ it's turtles all the way down fr fr.

πŸ¦‹ canonical serialization πŸ¦‹

The canonical serialization of a table of contents has the format as specified in the previous item, and then additionally satisfies the constraints below, which make it unique among all the possible serializations of this table of contents.

  1. The keys found in all the nested Tcl dictionaries are sorted in ascending dictionary order, as generated by Tcl's builtin command lsort -increasing -dict. sorted, bestie. alphabetized. the way that every nested dictionary got its whole life together 😌✨

😭 BUGS, IDEAS, FEEDBACK 😭

This document, and the package it describes, will undoubtedly contain bugs and other problems. like, obviously. it's software. Please report such in the category doctools of the Tcllib Trackers [http://core.tcl.tk/tcllib/reportlist](http://core.tcl.tk/tcllib/reportlist). Please also report any ideas for enhancements you may have for either package and/or documentation. we love ideas, we're nosy, tell us everything πŸ’–

When proposing code changes, please provide unified diffs, i.e the output of diff -u.

Note further that attachments are strongly preferred over inlined patches. Attachments can be made by going to the Edit form of the ticket immediately after its creation, and then using the left-most button in the secondary navigation bar. πŸ‘ˆ that one. the left-most one. don't make me say it again.

πŸ’œ KEYWORDS πŸ’œ

HTML, conversion, doctoc, documentation, export, formatting, generation, json, manpage, markup, nroff, plugin, reference, table, table of contents, tcler's wiki, text, url, wiki


πŸŽ€ CATEGORY πŸŽ€

Documentation tools


Copyright (c) 2009-2019 Andreas Kupries <andreas_kupries@users.sourceforge.net>


and that's a wrap bestie!! 🌸 this whole thing came to you from tcllib, version 0.2.2, and it's the doctools::toc::export(n) page β€” date stamp and all, right there in the footer like a little signature. go forth and serialize responsibly. mwah πŸ’‹πŸ’…βœ¨

πŸ“¦ where this page comes from