doctools::toc::parse(n)

💖 doctools::toc::parse — bestie edition 💖

okay so. this is the doctools::toc::parse manual page, part of the Documentation tools family. yes, the manpage name is literally right there in the title. no cap, it's giving "internal plumbing that actually slays" 💅

---

✨ NAME ✨

doctools::toc::parse — parsing text in doctoc format 🎀

---

🌸 SYNOPSIS 🌸

package require doctools::toc::parse ?0.2?

package require Tcl 8.5 9

package require doctools::toc::structure

package require doctools::msgcat

package require doctools::tcl::parse

package require fileutil

package require logger

package require snit

package require struct::list

package require struct::stack

::doctools::toc::parse text text

::doctools::toc::parse file path

::doctools::toc::parse includes

::doctools::toc::parse include add path

::doctools::toc::parse include remove path

::doctools::toc::parse include clear

::doctools::toc::parse vars

::doctools::toc::parse var set name value

::doctools::toc::parse var unset name

::doctools::toc::parse var clear ?pattern?

like, look at all those package requires. it's a whole squad. 🫶

---

🦋 DESCRIPTION 🦋

so this package hands you the commands to parse text written in the doctoc markup language and flip it into the canonical serialization of the table of contents that was encoded in that text. if you wanna know exactly what that serialization format looks like, go peek at the section ToC serialization format — it's the spec, it's authoritative, it ate.

also, real talk: this is an internal package of doctools. it's not for you to just vibe with directly — it exists for the higher-level packages that handle doctoc documents. iykyk. 💜

---

👑 API 👑

💫 ::doctools::toc::parse text text

takes the string sitting in text and parses it, assuming it holds a document written in the doctoc markup language. if that assumption turns out to be false, it throws an error. what do those errors look like? that's the whole Parse errors section below, go read it bestie.

when it does work? it returns the canonical serialization of the table of contents that was encoded in the text. again, the ToC serialization format section has the spec. ⭐

💫 ::doctools::toc::parse file path

literally the same thing as text, except the text it parses gets read from the file named by path. 📁

💫 ::doctools::toc::parse includes

this method returns the current list of search paths used when it goes looking for include files. 🌈

💫 ::doctools::toc::parse include add path

adds path to the list of paths that get searched when hunting down an include file. if path is already in the list, the call just gets ignored — no drama. the method returns the empty string as its result. ✨

💫 ::doctools::toc::parse include remove path

removes path from that list of paths searched when looking for an include file. if path isn't in the list, the call is ignored. returns the empty string as its result. 🎀

💫 ::doctools::toc::parse include clear

clears the whole list of search paths for include files. boom, gone. 💀

💫 ::doctools::toc::parse vars

returns a dictionary holding the current set of predefined variables that the vset markup command knows about during processing. 🍓

💫 ::doctools::toc::parse var set name value

adds the variable name to the set of predefined variables known to the vset markup command during processing, and gives it the specified value. returns the empty string as its result. 💜

💫 ::doctools::toc::parse var unset name

removes the variable name from the set of predefined variables known to the vset markup command during processing. returns the empty string as its result. 🌸

💫 ::doctools::toc::parse var clear ?pattern?

removes all variables matching pattern from the set of predefined variables known to the vset markup command during processing. returns the empty string as its result. 🧚

the pattern matching is done with string match, and the default pattern used when you don't specify one is *. so yeah, no pattern = nuke everything. iconic.

---

😭 PARSE ERRORS 😭

the format of the parse error messages thrown when the doctoc markup syntax gets violated is human readable and not intended for machines to process. so like, it's not documented. sorry bestie. 🙈

however — the errorCode attached to the message is machine-readable, and it has this format:

1. the error code will be a list, and each element describes a single error found in the input. the list has at least one element, possibly more. no empty lists here.
2. each error element will be a list containing six strings describing an error in detail. the strings will be:
   1. the path of the file the error occurred in. this may be empty. 📁
   2. the range of the token the error was found at. this range is a two-element list containing the offset of the first and last character in the range, counted from the beginning of the input (file). offsets are counted from zero.
   3. the line the first character after the error is on. lines are counted from one.
   4. the column the first character after the error is at. columns are counted from zero.
   5. the message code of the error. you can feed this value as an argument to msgcat::mc to get a localized error message — assuming the application made a suitable call to doctools::msgcat::init to initialize the necessary message catalogs (see package doctools::msgcat). 💅
   6. a list of details for the error, like the markup command involved. in the case of message code doctoc/include/syntax, this value is the set of errors found in the included file, using the format described right here. yes, it's recursive. it's giving inception. 🌀

---

🌈 [DOCTOC] NOTATION OF TABLES OF CONTENTS 🌈

the doctoc format for tables of contents — also called the doctoc markup language — is way too big to be covered in a single section. the interested reader should start with the document

1. doctoc language introduction

and then proceed from there to the formal specifications, i.e. the documents

1. doctoc language syntax and
2. doctoc language command reference.

do all that and you'll get a thorough understanding of the language. it's a journey, but you'll slay. 🔥

🔥 TOC SERIALIZATION FORMAT 🔥

okay bestie, so this is where we spell out the format the doctools v2 packages use to serialize tables of contents as immutable values — like, for transporting them, comparing them, all of that. it's giving "freeze it so nobody can touch it" energy. 🧊✨

we've got two flavors here: regular and canonical serializations. and here's the tea: a table of contents can have more than one regular serialization, but exactly one of them is ever gonna be the canonical one. 💅

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. 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 say it (an alternative description, if you will) is that 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. 👀
  • 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.
  • 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. 🌀 (yes, it's turtles all the way down, bestie)

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 is what makes it unique among all the possible serializations of this table of contents. slay. 💅

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 🐛

ngl, this document and the package it describes will undoubtedly contain bugs and other problems. like, it's basically guaranteed. 😭 please report such in the category doctools of the Tcllib Trackers [http://core.tcl.tk/tcllib/reportlist]. and please also report any ideas for enhancements you may have for either the package and/or the documentation — we wanna hear it. 🫶

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

also note further that attachments are strongly preferred over inlined patches. you can make attachments 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. 🎀

---

🔑 KEYWORDS 🔑

doctoc, doctools, lexer, parser

---

🗂️ CATEGORY 🗂️

Documentation tools

---

©️ COPYRIGHT ©️

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

---

okay and that's a wrap on this page, bestie!! 🎉 the footer says we're chilling in tcllib, section 1, page doctools::toc::parse(n), dated 1. go forth and parse those tables of contents, you absolute icon. 👑💖