doctools::idx::export(3tcl)

✨ NAME ✨

doctools::idx::export — exporting keyword indices 💅

okay so picture this: you've got a keyword index, right? And you need it in a different format. This is the package that makes that happen. No cap.

---

🦋 SYNOPSIS 🦋

package require doctools::idx::export ?0.2.2?

package require Tcl 8.5 9

package require struct::map

package require doctools::idx::structure

package require snit

package require pluginmgr

::doctools::idx::export objectName

objectName method ?arg arg ...?

objectName destroy

objectName export serial serial ?format?

objectName export object object ?format?

objectName config names

objectName config get

objectName config set name ?value?

objectName config unset pattern...

export serial configuration

---

🌸 DESCRIPTION 🌸

Bestie. This package hands you a class that manages all the plugins for exporting keyword indices into other formats — like converting them to docidx, HTML, whatever your heart desires. ✨

This is one of the three public pillars that keyword index management sits on top of. The other two pillars are:

1. Importing keyword indices, and
2. Holding keyword indices

Wanna know about the Concepts of keyword indices and all their little parts? Peep the same-named section. Wanna know about the data structure that's the major input to the manager objects this package gives you? That's the Keyword index serialization format section, babes.

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

1. the environment variable DOCTOOLS_IDX_EXPORT_PLUGINS,
2. the environment variable DOCTOOLS_IDX_PLUGINS,
3. the environment variable DOCTOOLS_PLUGINS,
4. the path ~/.doctools/idx/export/plugin
5. the path ~/.doctools/idx/plugin
6. the path ~/.doctools/plugin
7. the path ~/.doctools/idx/export/plugins
8. the path ~/.doctools/idx/plugins
9. the path ~/.doctools/plugins
10. the registry entry "HKEY_CURRENT_USER\SOFTWARE\DOCTOOLS\IDX\EXPORT\PLUGINS"
11. the registry entry "HKEY_CURRENT_USER\SOFTWARE\DOCTOOLS\IDX\PLUGINS"
12. the registry entry "HKEY_CURRENT_USER\SOFTWARE\DOCTOOLS\PLUGINS"

🙈 psst — those last three? They only get used when the package is running on a machine with the Windows(tm) operating system. So like, if that's not you, don't even worry about it.

The whole system ships with six predefined export plugins, and they are:

• docidx — See docidx export plugin for details.
• html — See html export plugin for details.
• json — See json export plugin for details.
• nroff — See nroff export plugin for details.
• text — See text export plugin for details.
• wiki — See wiki export plugin for details.

And hey — if you're the type who wants to write their own export plugin for some format? (plugin writers, I see you 👀) Then reading and actually understanding the section with the Export plugin API v2 reference is an absolute necessity, fr fr. That section spells out exactly how this package and its plugins talk to each other. Every detail. Periodt.

---

🧚 CONCEPTS 🧚

1. A keyword index consists of a (possibly empty) set of keywords.
2. Each keyword in the set is identified by its name.
3. Each keyword has a (possibly empty) set of references.
4. A reference can be associated with more than one keyword.
5. A reference not associated with at least one keyword is not possible however.
6. Each reference is identified by its target, specified as either an url or symbolic filename, depending on the type of reference (url, or manpage).
7. The type of a reference (url, or manpage) depends only on the reference itself, and not the keywords it is associated with.
8. In addition to a type each reference has a descriptive label as well. This label depends only on the reference itself, and not the keywords it is associated with.

💭 a few notes

1. Manpage references are meant for pointing at the documents the index is actually made for. Their target is a symbolic file name identifying the document — and export plugins are allowed to swap that symbolic name for an actual file name, if specified.
2. Url references, on the other hand, are meant for links to literally anything else, like websites. Their target is an url.
3. So url and manpage references share a namespace for their identifiers — but that should be zero problem, because manpage identifiers are symbolic filenames and as such they should never look like urls, which is what the identifiers for url references are. 🌈

---

👑 API 👑

💖 PACKAGE COMMANDS 💖

• ::doctools::idx::export objectName — This command creates a brand new export manager object, with a Tcl command attached to it whose name is objectName. That object command gets explained in full detail over in the sections Object command and Object methods. And heads up: the object command gets created under the current namespace if objectName isn't fully qualified — otherwise it lands in the namespace you specified. Slay.

🎀 OBJECT COMMAND 🎀

Every single object made by the ::doctools::idx::export command has this general form:

• objectName method ?arg arg ...? — The method method and its arg'uments are what determine exactly how the command behaves. See the section Object methods for the detailed specs, bestie.

✨ OBJECT METHODS ✨

• objectName destroy — This method destroys the object it's invoked for. bye bitch 👋
• objectName export serial serial ?format? — This method takes the canonical serialization of a keyword index stored in serial, and converts it to the specified format, using the export plugin for that format. If no plugin could be found for the format? An error is thrown. 💀 The string that the conversion process spits out is returned as the result of this method.

If you don't specify a format, the method defaults to docidx.

The specification of what a canonical serialization actually is lives in the section Keyword index serialization format.

And the plugin has to conform to the interface specified in the section Export plugin API v2 reference. No exceptions.

• objectName export object object ?format? — This one is a convenient little wrapper around the export serial method described right above. ✨ It expects object to be an object command that supports a serialize method returning the canonical serialization of a keyword index. It invokes that method, feeds the result straight into export serial, and returns the resulting string as its own result. Efficiency queen.
• objectName config names — Returns a list containing the names of all the configuration variables the object currently knows about.
• objectName config get — Returns a dictionary containing the names and values of all the configuration variables the object currently knows about.
• 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 pass a value, it just returns the current value without changing anything. chill like that.

⚠️ Nota bene: even though the user can set the predefined configuration variables user and format, doing so will have no effect — those values get internally overridden when invoking an import plugin. Don't waste your energy, babe.

• objectName config unset pattern... — Unsets all configuration variables matching the specified glob patterns. If you don't pass any pattern, it'll unset all currently defined configuration variables. Clean slate energy 💅

---

💅 EXPORT PLUGIN API V2 REFERENCE 💅

okay so plugins are literally the whole vibe this package uses to manage the support for any output format beyond the Keyword index serialization format. bestie, here's the API that the objects created by this package use to interact with their plugins. no cap.

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

1. A plugin is a package. periodt. 💅
2. The name of a plugin package has the form doctools::idx::export::FOO, where FOO is the name of the format the plugin will generate output for. This name is also the argument to provide to the various export methods of export manager objects to get a string encoding a keyword index in that format. slay.
3. The plugin can expect that the package doctools::idx::export::plugin is present, as indicator that it was invoked from a genuine plugin manager. iconic.
4. A plugin has to provide one command, with the signature shown below.

export serial configuration

Whenever an export manager of doctools::idx has to generate output for an index it will invoke this command. it's giving main character energy, ngl.

• string serial — This argument will contain the canonical serialization of the index for which to generate the output. The specification of what a canonical serialization is can be found in the section Keyword index serialization format. iykyk.
• dictionary configuration — This argument will contain the current configuration to apply to the generation, 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. (yes, "other other" — i'm just keeping it real. 😭)

• 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.
• file — This variable, if defined by the user of the index object is expected to contain the name of the input file for which the plugin is generating its output for.
• map — This variable, if defined by the user of the index object is expected to contain a dictionary mapping from symbolic file names used in the references of type manpage to actual paths (or urls). A plugin has to be able to handle the possibility that a symbolic name is without entry in this mapping. lowkey important.

5. A single usage cycle of a plugin consists of the invokations of the command export. This call has to leave the plugin in a state where another usage cycle can be run without problems. no stress. 🫶

---

🔑 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. obsessed.

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. the way that works is giving ✨unique✨.

📦 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. it's literally the one and only. 💅

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. 😭 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. we're all ears, bestie.

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. it's giving helpful. ✨

---

🏷️ KEYWORDS 🏷️

HTML, conversion, docidx, documentation, export, formatting, generation, index, json, keyword index, manpage, markup, nroff, plugin, reference, tcler's wiki, text, url, wiki

---

📂 CATEGORY 📂

Documentation tools

---

©️ COPYRIGHT ©️

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

---

Stay slay, bestie 💖 This was tcllib version 0.2.2, page doctools::idx::export(3tcl). Catch you on the flip side! ✨