doctools::idx::parse(n)

doctools::idx::parse(n) 💖

okay so bestie, welcome to doctools::idx::parse, a page from the Documentation tools manual 💅 she's an internal Tcl package and she parses text written in the docidx markup language and turns it into the canonical serialization of the keyword index. no cap, that's the whole vibe.

---

✨ SYNOPSIS ✨

package require doctools::idx::parse ?0.2?

package require Tcl 8.5 9

package require doctools::idx::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::idx::parse text text

::doctools::idx::parse file path

::doctools::idx::parse includes

::doctools::idx::parse include add path

::doctools::idx::parse include remove path

::doctools::idx::parse include clear

::doctools::idx::parse vars

::doctools::idx::parse var set name value

::doctools::idx::parse var unset name

::doctools::idx::parse var clear ?pattern?

---

🌸 DESCRIPTION 🌸

so this package hands you the commands to parse text written in the docidx markup language and convert it into the canonical serialization of the keyword index encoded in that text ✨. the spec for that format lives in the section Keyword index serialization format, bestie, go look.

and like, heads up: this is an internal package of doctools 🫶 — she's for use by the higher level packages that handle docidx documents. she's not out here for the general public, she's a backstage queen 👑

---

🎀 API 🎀

• ::doctools::idx::parse text text — takes the string inside text and parses it, assuming it contains a document written in the docidx markup language 🌈. if that assumption turns out to be false, an error gets thrown, periodt. the format of those errors is described down in Parse errors. when it does succeed, the command returns the canonical serialization of the keyword index that was encoded in the text 💖. again, see Keyword index serialization format for the spec of that format.
• ::doctools::idx::parse file path — same as text, except the text to parse is read from the file specified by path 📂.
• ::doctools::idx::parse includes — returns the current list of search paths used when looking for include files 👑
• ::doctools::idx::parse include add path — adds path to the list of paths searched when looking for an include file. the call is just ignored if path is already in the list (she's not dramatic about it). returns the empty string as its result ✨
• ::doctools::idx::parse include remove path — removes path from the list of paths searched when looking for an include file. ignored if path isn't in the list. returns the empty string as its result 💅
• ::doctools::idx::parse include clear — clears the list of search paths for include files 🧹
• ::doctools::idx::parse vars — returns a dictionary containing the current set of predefined variables known to the vset markup command during processing 💖
• ::doctools::idx::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::idx::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::idx::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 none is specified is *.

---

😭 PARSE ERRORS 😭

the format of the parse error messages thrown when the docidx markup syntax gets violated is human readable and not intended for processing by machines 🙈. as such, it is not documented. ngl, she said "read it with your eyes, not your code."

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

1. the error code will be a list, each element describing a single error found in the input. the list has at least one element, possibly more.
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. this value can be used as argument to msgcat::mc to obtain a localized error message, assuming that the application had a suitable call of 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 docidx/include/syntax this value is the set of errors found in the included file, using the format described here.

---

🌈 [DOCIDX] NOTATION OF KEYWORD INDICES 🌈

the docidx format for keyword indices — also called the docidx markup language — is too large to be covered in a single section 😭. the interested reader should start with the document

1. docidx language introduction

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

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

to get a thorough understanding of the language 👑📚

---

⭐ KEYWORD INDEX SERIALIZATION FORMAT ⭐

here we specify the format used by the doctools v2 packages to serialize keyword indices as immutable values for transport, comparison, etc. ✨

we distinguish between regular and canonical serializations. while a keyword index may have more than one regular serialization, only exactly one of them will be canonical 💅

regular serialization

1. an index serialization is a nested Tcl dictionary.
2. this dictionary holds a single key, doctools::idx, and its value. this value holds the contents of the index.
3. the contents of the index are a Tcl dictionary holding the title of the index, a label, and the keywords and references. the relevant keys and their values are:
   • title — the value is a string containing the title of the index.
   • label — the value is a string containing a label for the index.
   • keywords — the value is a Tcl dictionary, using the keywords known to the index as keys. the associated values are lists containing the identifiers of the references associated with that particular keyword. any reference identifier used in these lists has to exist as a key in the references dictionary, see the next item for its definition.
   • references — the value is a Tcl dictionary, using the identifiers for the references known to the index as keys. the associated values are 2-element lists containing the type and label of the reference, in this order. any key here has to be associated with at least one keyword, i.e. occur in at least one of the reference lists which are the values in the keywords dictionary, see previous item for its definition.
4. the type of a reference can be one of two values,
   • manpage — the identifier of the reference is interpreted as symbolic file name, referring to one of the documents the index was made for.
   • url — the identifier of the reference is interpreted as an url, referring to some external location, like a website, etc.

canonical serialization

the canonical serialization of a keyword index 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 the keyword index 👑

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.
2. the references listed for each keyword of the index, if any, are listed in ascending dictionary order of their labels, 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 😭 (not me being self-aware). 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 🫶

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. iykyk 💅

---

🔥 KEYWORDS 🔥

docidx, doctools, lexer, parser

---

👑 CATEGORY 👑

Documentation tools

---

🎀 COPYRIGHT 🎀

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

---

okay bestie that's the whole page 🫶 this is from tcllib, version 1 of the manual page — she's an icon, she's a legend, and she is the moment. go parse something gorgeous 💖✨🌈