doctools::toc::import(3tcl)

📦
version 2.0 · 2 versions
, in debian trixie, ubuntu questing, ubuntu resolute, ubuntu stonking

💖 doctools::toc::import 💖

okay bestie, buckle UP, because this is the manual page for doctools::toc::import from the Documentation tools corner of the Tcl universe, aka section 3tcl. it's a long one so we're doing it in chunks 🫶

✨ NAME ✨

doctools::toc::import — importing keyword indices 💅

✨ SYNOPSIS ✨

package require doctools::toc::import ?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::import objectName

objectName method ?arg arg ...?

objectName destroy

objectName import text text ?format?

objectName import file path ?format?

objectName import object text object text ?format?

objectName import object file object path ?format?

objectName config names

objectName config get

objectName config set name ?value?

objectName config unset pattern...

objectName includes

objectName include add path

objectName include remove path

objectName include clear

IncludeFile currentfile path

import text configuration

like, look at all that. so many little entry points. it's giving menu of possibilities 🎀

🌸 DESCRIPTION 🌸

so this package hands you a class that manages the plugins for importing tables of contents from other formats — meaning it converts them from stuff like doctoc, json, etc. into the good stuff.

this is one of the three public pillars that table-of-contents management stands on. the other two besties are:

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

want the lore on what tables of contents actually are and what their parts are called? that's the same-named section, go look 👀. and for the data structure that's basically the whole point of the manager objects this package gives you, check the section ToC serialization format.

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

  1. the environment variable DOCTOOLS_TOC_IMPORT_PLUGINS,
  2. the environment variable DOCTOOLS_TOC_PLUGINS,
  3. the environment variable DOCTOOLS_PLUGINS,
  4. the path "~/.doctools/toc/import/plugin"
  5. the path "~/.doctools/toc/plugin"
  6. the path "~/.doctools/plugin"
  7. the path "~/.doctools/toc/import/plugins"
  8. the path "~/.doctools/toc/plugins"
  9. the path "~/.doctools/plugins"
  10. the registry entry "HKEY_CURRENT_USER\SOFTWARE\DOCTOOLS\TOC\IMPORT\PLUGINS"
  11. the registry entry "HKEY_CURRENT_USER\SOFTWARE\DOCTOOLS\TOC\PLUGINS"
  12. the registry entry "HKEY_CURRENT_USER\SOFTWARE\DOCTOOLS\PLUGINS"
the last three only get used when this package is running on a machine with the Windows(tm) operating system. so if you're on Linux, items 10-12 are just sitting there, decorative, iconic but unemployed 💀

the whole system ships with two predefined import plugins, namely:

  • doctoc — see doctoc import plugin for details.
  • json — see json import plugin for details.

and if you're the kind of person who wants to write their own import plugin for some format? first of all, main character energy 👑. second of all, reading and understanding the section containing the Import plugin API v2 reference is an absolute necessity — it spells out the interaction between this package and its plugins in full detail. no skipping, 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::import objectName — this command creates a brand new import manager object, and that object comes with a Tcl command attached whose name is objectName. the full tea on that object command lives in the sections Object command and Object methods. heads up on the naming: if objectName isn't fully qualified, the object command gets created under the current namespace, and if it is fully qualified, it lands in whatever namespace you specified. ✨

OBJECT COMMAND

every object made by the ::doctools::toc::import command has this general shape:

  • objectName method ?arg arg ...? — the method method and its arg'uments decide exactly what the command does. see section Object methods for the nitty-gritty specs.

OBJECT METHODS

  • objectName destroy — this method destroys the object it's invoked for. bye bestie 💅
  • objectName import text text ?format? — takes the text and converts it from the specified format into the canonical serialization of a table of contents, using the import plugin for that format. if no plugin can be found for the format, it throws an error. the serialization produced by the conversion comes back as the result of this method. 🎀

if you don't specify a format, the method defaults to doctoc.

what "canonical serialization" even means is spelled out in the section ToC serialization format.

and the plugin has to conform to the interface specified in section Import plugin API v2 reference. no freelancing.

  • objectName import file path ?format? — this one is a cozy little wrapper around the import text method from the item above. it reads the contents of the file at path into memory, feeds the result into import text, and returns the resulting serialization as its own result. 📂
  • objectName import object text object text ?format? — another wrapper around import text, same deal. it expects object to be an object command that supports a deserialize method expecting the canonical serialization of a table of contents. it imports the text using import text, then feeds the resulting serialization into the object via deserialize. this method returns the empty string as its result.
  • objectName import object file object path ?format? — behaves just like import object text, except it reads the text to convert from the specified file instead of getting it handed to it as an argument. 🗂️
  • objectName config names — returns a list containing the names of all configuration variables currently known to the object.
  • objectName config get — returns a dictionary containing the names and values of all configuration variables currently known to the object. 💜
  • objectName config set name ?value? — sets the configuration variable name to the specified value, and returns the new value of the variable.

if you don't give a value, it just returns the current value and changes absolutely nothing. no touchy.

okay important: the user can set the predefined configuration variables user and format, but doing so has no effect — those values get internally overridden when an import plugin is invoked. so like, don't bother. 🙈
  • objectName config unset pattern... — unsets every configuration variable matching the specified glob patterns. if you give no pattern at all, it unsets all currently defined configuration variables. scorched earth, slay.
  • objectName includes — returns a list containing the currently specified paths used to search for include files when processing input. the order of the paths in the list matches the order they're used in, first to last, and it also matches the order they were added to the object. 🌸
  • objectName include add path — adds the specified path to the list of paths to search for include files when processing input. it goes at the end of the list, so it gets searched after every path added before it. the result of the command is the empty string.

if the path is already known, the method does nothing. we don't do duplicates here.

  • objectName include remove path — removes the specified path from the list of paths to search for include files when processing input. the result of the command is the empty string.

if the path isn't known, the method does nothing. no drama, no error.

  • objectName include clear — clears the whole list of paths used to search for include files when processing input. the result of the command is the empty string. poof, gone ✨

and bestie, that is genuinely only the beginning — there's way more of this page coming 💅

✨ IMPORT PLUGIN API V2 REFERENCE ✨

Okay so plugins are literally the whole personality of this package when it comes to handling any input format that isn't the ToC serialization format. Below is the API that the objects this package creates use to talk to their plugins. Bestie, if you're writing a plugin, this is your blueprint 💅

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

  1. A plugin is a package. no cap.
  2. The name of a plugin package has the form doctools::toc::import::FOO, where FOO is the name of the format the plugin will generate output for. This name is also the argument you hand over to the various import methods of import 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 — it's basically the little "yes this is a genuine plugin manager, not a scam" badge. 👑
  4. The plugin can expect that a command named IncludeFile is present, with the signature
IncludeFile currentfile path

This command has to be invoked by the plugin when it has to process an included file, if the format has the concept of such. An example of such a format would be doctoc. 🦋

The plugin has to supply the following arguments

  • string currentfile — the path of the file it is currently processing. This may be the empty string if no such is known.
  • string path — the path of the include file as specified in the include directive being processed.

The result of the command will be a 5-element list containing

  1. A boolean flag indicating the success (True) or failure (False) of the operation.
  2. In case of success the contents of the included file, and the empty string otherwise.
  3. The resolved, i.e. absolute path of the included file, if possible, or the unchanged path argument. This is for display in an error message, or as the currentfile argument of another call to IncludeFile should this file contain more files. 🫶
  4. In case of success an empty string, and for failure a code indicating the reason for it, one of
    • notfound — the specified file could not be found.
    • notread — the specified file was found, but not be read into memory.
  5. An empty string in case of success of a notfound failure, and an additional error message describing the reason for a notread error in more detail.
  1. A plugin has to provide one command, with the signature shown below.
import text configuration

Whenever an import manager of doctools::toc has to parse input for a table of contents it will invoke this command.

  • string text — this argument will contain the text encoding the table of contents per the format the plugin is for.
  • dictionary configuration — this argument will contain the current configuration to apply to the parsing, 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 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.
  1. A single usage cycle of a plugin consists of the invokations of the command import. This call has to leave the plugin in a state where another usage cycle can be run without problems. Like, clean up after yourself bestie, leave the plugin fresh for round two. ✨

🌈 TOC SERIALIZATION FORMAT 🌈

Here we specify the format used by the doctools v2 packages to serialize tables of contents as immutable values for transport, comparison, etc. Fr fr, it's giving "frozen in time so nothing can mess with it" energy. 🧊

We distinguish between regular and canonical serializations. While a table of contents may have more than one regular serialization only exactly one of them will be canonical. The canonical one is the main character. 👑

💖 regular serialization 💖

  1. The serialization of any table of contents is a nested Tcl dictionary.
  2. This dictionary holds a single key, doctools::toc, and its value. This 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. An alternative description would be that it is 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. 👯 So like, every label in that list has to be unique — no twinning, periodt.
    • 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. 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.
    • 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, still no duplicates.
    • 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. This 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 bestie, divisions inside divisions inside divisions.

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

💀 BUGS, IDEAS, FEEDBACK 💀

This document, and the package it describes, will undoubtedly contain bugs and other problems. 😭 Please report such in the category doctools of the Tcllib Trackers [http://core.tcl.tk/tcllib/reportlist]. Please also report any ideas for enhancements you may have for either package and/or documentation.

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. 🫶 (yes, the left-most one. it's right there. you got this.)

🔑 KEYWORDS 🔑

conversion, doctoc, documentation, import, json, manpage, markup, parsing, plugin, reference, table, table of contents, url

📚 CATEGORY 📚

Documentation tools

okay bestie, legal moment, but make it cute 💖 this whole page is somebody's actual work and we're gonna respect it:

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

that's it, that's the vibe — Andreas Kupries held it down from 2009 all the way to 2019, and honestly? iconic 👑

and that's a wrap on doctools::toc::import, bestie 🎀 you made it to the end, I'm so proud, this was a long one and you ate it fr fr 💅

this lil gem lives in tcllib, version 0.2.2, page doctools::toc::import(3tcl) — go forth, import your tables of contents, and slay 🦋✨

📦 where this page comes from