doctools::...:structure(3tcl)

πŸ“¦
version 2.0 Β· 2 versions
, in debian trixie, ubuntu questing, ubuntu resolute, ubuntu stonking

πŸ’– doctools::idx::structure β€” bestie edition πŸ’–

okay so. this is a page from the Documentation tools manual (manual name: Documentation tools, Tcllib), and it's about doctools::idx::structure. that's the Docidx serialization utilities, babes. serialization. slay. πŸŽ€


✨ NAME ✨

doctools::idx::structure β€” Docidx serialization utilities. that's the whole vibe. it does serialization. it's for indices. periodt. πŸ‘‘


🌈 SYNOPSIS 🌈

package require doctools::idx::structure ?0.2?

package require Tcl 8.5 9

package require logger

package require snit

::doctools::idx::structure verify serial ?canonvar?

::doctools::idx::structure verify-as-canonical serial

::doctools::idx::structure canonicalize serial

::doctools::idx::structure print serial

::doctools::idx::structure merge seriala serialb

πŸ¦‹ DESCRIPTION πŸ¦‹

so this package hands you the commands to work with the serializations of keyword indices, the kind the doctools system v2 manages, exactly as specified in the section Keyword index serialization format. iykyk. πŸ’…

and listen β€” this is an internal package of doctools. it's for the higher-level packages that handle keyword indices and convert them into and out of other formats, like documents written using docidx markup. it's not out here for main character moments, it's behind the scenes doing the work. πŸ™ˆ


πŸ’… API πŸ’…

  • ::doctools::idx::structure verify serial ?canonvar? β€” this one checks that whatever's inside serial is a valid regular serialization of a keyword index, and bestie, if it's not, it will throw an error. no cap. the result of the command is the empty string.

and if you also pass canonvar? it's read as the name of a variable in the calling context. that variable gets written to if and only if serial is a valid regular serialization. its value will be a boolean β€” True means the serialization is valid and canonical (iconic), False means it's valid but not canonical. both are fine, one's just extra special. ✨

for the spec of regular and canonical keyword index serializations, go peek at the section Keyword index serialization format.

  • ::doctools::idx::structure verify-as-canonical serial β€” same energy, higher standards. checks that serial is a valid canonical serialization of a keyword index, and throws an error if it isn't. result is the empty string.

again, the section Keyword index serialization format has the spec for canonical keyword index serializations.

  • ::doctools::idx::structure canonicalize serial β€” this one assumes serial holds a valid regular serialization of a keyword index, and will throw an error if that assumption is wrong (so like, don't test it, it's not testing you back 😭).

then it converts the input into the canonical serialization of the contained keyword index and returns it. and if the input is already canonical? it comes right back to you unchanged. queen behavior. πŸ‘‘

spec for regular and canonical serializations β†’ section Keyword index serialization format.

  • ::doctools::idx::structure print serial β€” assumes serial contains a valid regular serialization of a keyword index and returns a string with that index in a human readable form. cute for your eyeballs. πŸ“
heads up bestie: the exact format of that form is not specified and you cannot rely on it for parsing or any other machine-based activities. it's for looking at. that's it. don't build anything on it. πŸ’€

spec for regular serializations β†’ section Keyword index serialization format.

  • ::doctools::idx::structure merge seriala serialb β€” takes the regular serializations of two keyword indices and makes their union. the result is the canonical serialization of that unified keyword index. it's giving collaborative. 🫢

Title and label of the resulting index come from the index contained in serialb. the set of keys, references, and their connections is the union of the set of keys and references of the two inputs.

spec for regular and canonical serializations β†’ section Keyword index serialization format.


🌸 KEYWORD INDEX SERIALIZATION FORMAT 🌸

here's where we specify the format the doctools v2 packages use to serialize keyword indices as immutable values for transport, comparison, etc.

we distinguish between regular and canonical serializations. a keyword index may have more than one regular serialization, but only exactly one of them will be canonical. there can only be one. main character energy fr fr. ⭐

πŸ’œ regular serialization

  1. an index serialization is a nested Tcl dictionary.
  2. this dictionary holds a single key, doctools::idx, and its value. that 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.

  1. the type of a reference can be one of two values:
    • manpage β€” the identifier of the reference is interpreted as a symbolic file name, referring to one of the documents the index was made for.
    • url β€” the identifier of the reference is interpreted as a 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. it's giving humble. 😭 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 them. 🫢

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. you got this. πŸ’–


πŸ”₯ KEYWORDS πŸ”₯

deserialization, docidx, doctools, serialization


πŸ‘‘ CATEGORY πŸ‘‘

Documentation tools


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


okay that's the whole page, bestie. this one's from tcllib, version 0.2, and it's doctools::...:structure(3tcl) β€” the Documentation tools manual, and yes the page title really does abbreviate itself like that, iconic honestly. mwah. πŸ’…βœ¨πŸ¦‹

πŸ“¦ where this page comes from