doctools::idx::import(n)

📦
version 2.0 · 2 versions
, in fedora 43, fedora 44, nixos 26.05, nixpkgs unstable

doctools::idx::import ✨

part of the Documentation tools family, and yeah, this is the (n) manual page bestie 💖

🌸 SYNOPSIS 🌸

package require doctools::idx::import ?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::import objectName

objectName method ?arg arg ...?

objectName destroy

objectName import text text ?format?

objectName import file path ?format?

objectName import object text object text ?format?

objectName import object file object path ?format?

objectName config names

objectName config get

objectName config set name ?value?

objectName config unset pattern...

objectName includes

objectName include add path

objectName include remove path

objectName include clear

IncludeFile currentfile path

import text configuration

🦋 DESCRIPTION 🦋

Okay so, this package hands you a class that manages all the plugins for importing keyword indices from other formats — like, converting them from something like docidx, json, etc. into the good stuff.

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

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

Wanna know about the Concepts of keyword indices and all their little parts? Go read the section with that exact same name. And if you wanna know about the data structure that is the major output of the manager objects this package gives you, go check the section Keyword index serialization format.

The plugin system in this class is built on top of the pluginmgr package, and it's configured to hunt for plugins using these, in order:

  1. the environment variable DOCTOOLS_IDX_IMPORT_PLUGINS,
  2. the environment variable DOCTOOLS_IDX_PLUGINS,
  3. the environment variable DOCTOOLS_PLUGINS,
  4. the path ~/.doctools/idx/import/plugin
  5. the path ~/.doctools/idx/plugin
  6. the path ~/.doctools/plugin
  7. the path ~/.doctools/idx/import/plugins
  8. the path ~/.doctools/idx/plugins
  9. the path ~/.doctools/plugins
  10. the registry entry "HKEY_CURRENT_USER\SOFTWARE\DOCTOOLS\IDX\IMPORT\PLUGINS"
  11. the registry entry "HKEY_CURRENT_USER\SOFTWARE\DOCTOOLS\IDX\PLUGINS"
  12. the registry entry "HKEY_CURRENT_USER\SOFTWARE\DOCTOOLS\PLUGINS"
Heads up bestie: those last three? Only used when the package is running on a machine with Windows(tm) as the operating system. No Windows, no registry entries. 🪟

The whole system ships with two predefined import plugins, and they are:

  • docidx — See docidx import plugin for details.
  • json — See json import plugin for details.

And if you're a reader who wants to write their own import plugin for some format? Then, like, reading and understanding the section with the Import plugin API v2 reference is an absolute necessity, no cap. That section spells out in full detail how this package and its plugins talk to each other. 📖

🎀 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 intended to be used for references to the documents the index is made for. Their target is a symbolic file name identifying the document, and export plugins may replace symbolic with actual file names, if specified.
  2. Url references are intended on the othre hand are inteded to be used for links to anything else, like websites. Their target is an url.
  3. While url and manpage references share a namespace for their identifiers, this should be no problem, given that manpage identifiers are symbolic filenames and as such they should never look like urls, the identifiers for url references.

💅 API 💅

🌈 PACKAGE COMMANDS 🌈

  • ::doctools::idx::import objectName — This command creates a brand new import manager object with an associated Tcl command whose name is objectName. That object command gets explained in full detail down in the sections Object command and Object methods. The object command is created under the current namespace if objectName isn't fully qualified, and in the specified namespace otherwise. ✨

👑 OBJECT COMMAND 👑

Every object created by the ::doctools::idx::import command has this general form, periodt:

  • objectName method ?arg arg ...? — The method method and its arg'uments decide the exact behavior of the command. Detailed specs live in the section Object methods.

🧚 OBJECT METHODS 🧚

  • objectName destroy — This method destroys the object it is invoked for. bye bestie 👋
  • objectName import text text ?format? — This method takes the text and converts it from the specified format into the canonical serialization of a keyword index, using the import plugin for that format. An error is thrown if no plugin could be found for the format. The serialization produced by the conversion process is returned as the result of this method.

If no format is specified, the method defaults to docidx. 🍓

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

The plugin has to conform to the interface specified in the section Import plugin API v2 reference.

  • objectName import file path ?format? — This method is a convenient little wrapper around the import text method from the previous item. It reads the contents of the specified file into memory, feeds that result into import text, and returns the resulting serialization as its own result. 🫶
  • objectName import object text object text ?format? — Another convenient wrapper around import text from the previous item. It expects that object is an object command supporting a deserialize method that expects the canonical serialization of a keyword index. It imports the text using import text and then feeds the resulting serialization into the object via deserialize. This method returns the empty string as its result.
  • objectName import object file object path ?format? — This method behaves exactly like import object text, except it reads the text to convert from the specified file instead of being handed it as an argument. 📂
  • objectName config names — This method returns a list containing the names of all configuration variables currently known to the object. 📝
  • objectName config get — This method returns a dictionary containing the names and values of all configuration variables currently known to the object. 🔍
  • objectName config set name ?value? — This method sets the configuration variable name to the specified value and returns the new value of the variable.

If no value is specified it simply returns the current value, without changing anything. 🙈

Note: 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. So like… don't bother bestie.
  • objectName config unset pattern... — This method unsets all configuration variables matching the specified glob patterns. If no pattern is specified, it will unset all currently defined configuration variables. 💀
  • objectName includes — This method returns a list containing the currently specified paths to use when searching for include files while processing input. The order of paths in the list matches the order they're used in, first to last, and also matches the order they were added to the object. 🌸
  • objectName include add path — This method adds the specified path to the list of paths used to search for include files when processing input. The path gets added to the end of the list, so it gets searched after all previously added paths. The result of the command is the empty string.

The method does nothing if the path is already known. ✨

  • objectName include remove path — This method removes the specified path from the list of paths used to search for include files when processing input. The result of the command is the empty string.

The method does nothing if the path is not known. 🦋

  • objectName include clear — This method clears the list of paths used to search for include files when processing input. The result of the command is the empty string. 🧹

💖 IMPORT PLUGIN API V2 REFERENCE 💖

okay so bestie, plugins are literally the whole reason this package can handle input formats beyond the Keyword index serialization format. This section is the API spec — the rules the objects made by this package follow when they talk to their plugins. It's giving contract energy. 🫶

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

  1. A plugin is a package.
  2. The name of a plugin package has the form doctools::idx::import::FOO, where FOO is the name of the format the plugin will generate output for. That name is also the argument you hand to the various import methods of import manager objects to get a string encoding a keyword index in that format. iykyk 💅
  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.
  4. The plugin can expect that a command named IncludeFile is present, with the signature
IncludeFile currentfile path

This command has to be invoked by the plugin when it has to process an included file, if the format has the concept of such. An example of such a format would be docidx.

The plugin has to supply the following arguments:

  • string currentfile — the path of the file it is currently processing. This may be the empty string if no such is known.
  • string path — the path of the include file as specified in the include directive being processed.

The result of the command will be a 5-element list containing:

  1. A boolean flag indicating the success (True) or failure (False) of the operation.
  2. In case of success the contents of the included file, and the empty string otherwise.
  3. The resolved, i.e. absolute path of the included file, if possible, or the unchanged path argument. This is for display in an error message, or as the currentfile argument of another call to IncludeFile should this file contain more files.
  4. In case of success an empty string, and for failure a code indicating the reason for it, one of
    • notfound — the specified file could not be found.
    • notread — the specified file was found, but not be read into memory.
  5. An empty string in case of success of a notfound failure, and an additional error message describing the reason for a notread error in more detail.
  1. A plugin has to provide one command, with the signature shown below.
import text configuration

Whenever an import manager of doctools::idx has to parse input for an index it will invoke this command.

  • string text — this argument will contain the text encoding the index per the format the plugin is for.
  • dictionary configuration — this argument will contain the current configuration to apply to the parsing, 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.

  • 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.
  1. A single usage cycle of a plugin consists of the invokations of the command import. This call has to leave the plugin in a state where another usage cycle can be run without problems. 🔁

🌈 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. (yes, "for transport, comparison, etc." — iconic combo fr fr ✨)

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.

  1. 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 manifesting bugs but also being honest about it 💀) Please report such in the category doctools of the Tcllib Trackers at 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. 📎✨

🔑 KEYWORDS 🔑

conversion, docidx, documentation, import, index, json, keyword index, manpage, markup, parsing, plugin, reference, url

🗂️ CATEGORY 🗂️

Documentation tools

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

and that's a wrap, bestie 🫶 this whole thing lives in the tcllib source, version 0.2.2, in the doctools::idx::import(n) manpage. go forth and import your indices, you absolute icon 👑✨

📦 where this page comes from