doctools::toc::parse(3tcl)
π¦ doctools::toc::parse π¦
okay bestie, quick vibe check: this is doctools::toc::parse, living in the Documentation tools manual, section 3tcl. pull up a chair, we're parsing tables of contents and it's gonna be iconic π
β¨ NAME β¨
doctools::toc::parse β literally just parsing text that's written in doctoc format, no big deal π
π 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?
π DESCRIPTION π
so basically this package hands you the commands to parse text written in the doctoc markup language and turn it into the canonical serialization of the table of contents that was chillin' inside that text. if you wanna know exactly what that format looks like, go peek at the ToC serialization format section. iykyk π«Ά
ngl, this is an internal package of doctools β it's meant to be used by the higher level packages that actually handle doctoc documents. it's the backstage crew, not the main character. (well. mostly not the main character.) π
πΈ API πΈ
::doctools::toc::parse text textβ bestie, this one takes the string sitting intextand 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, periodt. the format of those errors is spelled out in the Parse errors section. when it does slay, it returns the canonical serialization of the table of contents that was encoded in the text β again, check ToC serialization format for the spec β¨::doctools::toc::parse file pathβ same energy astext, except the text it parses gets read from the file named bypath. that's it, that's the whole thing π::doctools::toc::parse includesβ returns the current list of search paths it uses when it goes looking for include files π::doctools::toc::parse include add pathβ addspathto the list of paths searched when looking for an include file. ifpathis already in the list, the call just gets ignored, no drama. returns the empty string as its result π::doctools::toc::parse include remove pathβ removespathfrom the list of paths searched when looking for an include file. ifpathisn't in the list, the call is ignored, we move on. returns the empty string as its result π§::doctools::toc::parse include clearβ clears the whole list of search paths for include files. wipeout. bye π::doctools::toc::parse varsβ returns a dictionary containing the current set of predefined variables that thevsetmarkup command knows about during processing π::doctools::toc::parse var set name valueβ adds the variablenameto the set of predefined variables known to thevsetmarkup command during processing, and gives it the specifiedvalue. returns the empty string as its result β¨::doctools::toc::parse var unset nameβ removes the variablenamefrom the set of predefined variables known to thevsetmarkup command during processing. returns the empty string as its result π«Ά::doctools::toc::parse var clear ?pattern?β removes all variables matchingpatternfrom the set of predefined variables known to thevsetmarkup 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 = everything goes π§Ή
π PARSE ERRORS π
the format of the parse error messages that get thrown when the doctoc markup syntax gets violated is human readable and not intended for processing by machines. so obviously it's not documented. you read it with your eyeballs, not your parser π
but β the errorCode attached to the message is machine-readable, and here's its format:
- the error code is 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 π
- each error element is a list containing six strings describing an error in detail. those strings are:
- the path of the file the error occurred in. this may be empty.
- 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.
- the line the first character after the error is on. lines are counted from one.
- the column the first character after the error is at. columns are counted from zero.
- the message code of the error. this value can be used as an argument to
msgcat::mcto obtain a localized error message β assuming the application had a suitable call ofdoctools::msgcat::initto initialize the necessary message catalogs (see packagedoctools::msgcat). - a list of details for the error, like the markup command involved. in the case of message code
doctoc/include/syntaxthis value is the set of errors found in the included file, using the format described right here. recursion, bestie, it's giving inception π
π [DOCTOC] NOTATION OF TABLES OF CONTENTS π
the doctoc format for tables of contents β also called the doctoc markup language β is too large to be covered in a single section. it's a whole universe, not a paragraph π
so if you're the interested reader (and honestly? you should be), start with this document:
doctoc language introduction
and then proceed from there to the formal specifications, i.e. the documents:
doctoc language syntaxanddoctoc language command reference
...and that's how you get a thorough understanding of the language. study era fr fr πβ¨
π TOC SERIALIZATION FORMAT π
okay so bestie, this is the part where we talk about how doctools v2 packages serialize tables of contents into immutable values β you know, so they can be shipped around, compared, all that good stuff β¨
We split it into two flavors: regular and canonical serializations. A table of contents can have more than one regular serialization, but exactly one of them gets to be the canonical one. Only one. It's giving main character π
regular serialization
- The serialization of any table of contents is a nested Tcl dictionary. yes really, it's dicts all the way down πͺ
- This dictionary holds a single key,
doctools::toc, and its value. That value holds the contents of the table of contents. - 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. iconic, no notes π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. Or, if you wanna say it a different way: it's a Tcl dictionary holding a single key β the item type β mapped to the item description. Same thing, different vibe π¦
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 anidfor the referenced document, alabel, 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, no twin labels bestie, it's a whole thing π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 optionalidto 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. again! unique labels only, periodt π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 keyworditemsused to describe the whole table of contents, see above. This closes the recursive definition of the structure β divisions holding the same type of elements as the whole table of contents, including other divisions. πͺπͺπͺ
ngl the original manpage spells it "recusrive" and we're just gonna let that be its little quirk π
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. like, there's exactly one glow-up version β¨
- 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. no cap π₯
π BUGS, IDEAS, FEEDBACK π
This document, and the package it describes, will undoubtedly contain bugs and other problems. π it's not a maybe, it's a will. Please report such in the category doctools of the Tcllib Trackers at [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 want the ideas too, fr fr π«Ά
When proposing code changes, please provide unified diffs, i.e the output of diff -u. no vibes-based patches, actual diffs please π
Also note: attachments are strongly preferred over inlined patches. You can attach stuff 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. go forth and attach π
π KEYWORDS π
doctoc, doctools, lexer, parser
π CATEGORY π
Documentation tools
πΈ COPYRIGHT πΈ
Copyright (c) 2009 Andreas Kupries <andreas_kupries@users.sourceforge.net>
and that's a wrap bestie!! π this whole thing is from the tcllib source, version 1, dated 2009, and it's the doctools::toc::parse(3tcl) page β go parse some tables of contents, you absolute icon π¦β¨ slay π«Ά
π¦ where this page comes from
- debian trixie: tcllib 2.0+dfsg-4 Β· Tcl
- ubuntu questing: tcllib 2.0+dfsg-4
- ubuntu resolute: tcllib 2.0+dfsg-5 Β· Tcl
- ubuntu stonking: tcllib 2.0+dfsg-6 Β· Tcl
- Copyright (c) 2009 Andreas Kupries <andreas_kupries@users\&.sourceforge\&.net>
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms