doctools_plugin_apiref(3tcl)

doctools_plugin_apiref 💖 (the 3tcl one, bestie)

okay so. sit down. hydrate. this is the doctools plugin API reference and it's a whole vibe, and also it's the spec for how the doctools package and its plugins talk to each other. yes it's long. yes we're doing it. no we're not skipping anything. periodt. 💅

---

✨ NAME ✨

doctools_plugin_apiref — doctools plugin API reference 🎀

---

🌸 SYNOPSIS 🌸

dt_copyright

dt_file

dt_mainfile

dt_fileid

dt_fmap symfname

dt_format

dt_imgdata key extensions

dt_imgdst key extensions

dt_imgsrc key extensions

dt_lnesting

dt_module

dt_read file

dt_source file

dt_user

ex_cappend text

ex_cget varname

ex_cis cname

ex_cname

ex_cpop cname

ex_cpush cname

ex_cset varname value

ex_lb ?newbracket?

ex_rb ?newbracket?

fmt_initialize

fmt_listvariables

fmt_numpasses

fmt_postprocess text

fmt_setup n

fmt_shutdown

fmt_varset varname text

fmt_plain_text text

---

💜 DESCRIPTION 💜

so this doc is for plugin writers specifically — like, the devs who wanna write a doctools formatting engine for some output format X. yes, whatever X is for you, go off. 🦋

it lays out the interaction between the doctools package and its plugins, i.e. the interface that every single doctools formatting engine has to comply with. no cap.

and like, heads up: this document is dealing with version 1 of that interface. 🫶

if you're the other kind of reader — the one who's way more into the markup language itself — you wanna start with the doctools language introduction and then proceed from there to the formal specifications, meaning the doctools language syntax and the doctools language command reference. that's your path, bestie. ✨

---

🌈 OVERVIEW 🌈

the API for a doctools formatting engine is split into two major sections. two. iconic structure. 💅

on one side, we have a set of commands through which the plugin can query the frontend. these commands are provided by the frontend and linked into the plugin interpreter. detailed spec? that's the FRONTEND COMMANDS section, go look.

and on the other side, the plugin has to provide its own set of commands, which the frontend will then call in a specific sequence while it's processing input. those ones fall into two categories again — management and formatting. the detailed spec for those lives in PLUGIN COMMANDS and its subsections. 💖

---

👑 FRONTEND COMMANDS 👑

this section specifies the whole set of commands through which a plugin — also known as a doctools formatting engine, same thing, different name, main character energy — is able to query the frontend. these commands are provided by the frontend and linked into the plugin interpreter. 🔥

so basically: a doctools formatting engine can assume that all of the following commands are present whenever any of its own commands (the ones in PLUGIN COMMANDS) are executed. 💯

beyond that, it can also assume it has full access to its own safe interpreter, which means it can't damage the other parts of the processor, and it also can't damage the filesystem. but okay, plot twist — it can either kill or hang the whole process, by exiting, or by running an infinite loop. so like. use your powers responsibly bestie 😭

coming back to the imported commands: everything with the dt_ prefix gives you limited access to specific parts of the frontend, whereas everything with the ex_ prefix gives you access to the state of the textutil::expander object — the one doing the main parsing of the input within the frontend. those ones should not be except under very special circumstances. 🚨

---

🎀 the dt_ girlies 🎀

• dt_copyright — query command 💖. hands you back a string with the copyright info the doctools processor was configured with. the relevant option is -copyright).
• dt_file — query command 💖. gives you the full path of the file containing the input the engine is currently processing. and yes, that might be an included file, not the main one. sneaky.
• dt_mainfile — query command 💖. gives you the full path of the toplevel file containing the input currently being processed by the engine.
• dt_fileid — query command 💖. gives you the name of the file containing the input currently being processed by the engine — but with no path, and no extension. just the bare name, serving face.
• dt_fmap symfname — query command 💖. gives you the actual pathname to use in the output, in place of the symbolic filename symfname. and if no mapping was ever established for symfname, it just hands you back the input unchanged. (the mappings you need are set up with the method map of a frontend, which is explained in the OBJECT METHODS section of the docs for the package doctools.)
• dt_format — query command 💖. gives you the name of the format associated with the doctools formatting engine.
• dt_imgdata key extensions — query command 💖. access to the image map. it looks for an image recorded under key and having the specified extensions. if a matching image is found, its data is returned as the result of the command. otherwise you get an empty string. 🙈
• dt_imgdst key extensions — query command 💖. access to the image map. looks for an image recorded under key and having the specified extensions. if a matching image is found, its destination path in the output is returned as the result of the command. otherwise, empty string. 🙈
• dt_imgsrc key extensions — query command 💖. access to the image map. looks for an image recorded under key and having the specified extensions. if a matching image is found, its origin path is returned as the result of the command. otherwise, empty string. 🙈
• dt_lnesting — query command 💖. gives you the number of lists that are currently open. count 'em.
• dt_module — query command 💖. gives you the name of the module that the input currently being processed belongs to.
• dt_read file — controlled filesystem access 🔒. returns the contents of file for whatever use the plugin desires. BUT — only files that are either in the same directory as the file containing the engine, or below it, can be loaded. trying to load a file outside of that directory causes an error. do not test it. actually, test it, but expect the error. 😭
• dt_source file — controlled filesystem access 🔒. this command lets the doctools formatting engine load additional Tcl code it might need. same rules — only files either in the same directory as the file containing the engine, or below it, can be loaded. trying to load a file outside of this directory causes an error. 🚫
• dt_user — query command 💖. gives you the name of the current user, as known to the tcl interpreter that the frontend controlling the formatting engine lives in. hi bestie 👋

---

🦋 the ex_ girlies (handle with care) 🦋

these are the ones that touch the textutil::expander state. the docs literally say they should not be used except under very special circumstances. so like... be so for real before you reach for these. 💀

• ex_cappend text — appends a string to the output in the current context. this command should rarely be used by macros or application code. like, rarely rarely.
• ex_cget varname — retrieves the value of variable varname, as defined in the current context. 💖
• ex_cis cname — determines whether or not the name of the current context is cname. yes/no situation.
• ex_cname — returns the name of the current context. that's it. that's the whole job. 👑
• ex_cpop cname — pops a context off the context stack, returning all accumulated output in that context. the context must be named cname, or an error results. no exceptions bestie.
• ex_cpush cname — pushes a context named cname onto the context stack. and it must be popped by cpop before expansion ends, or an error results. don't leave it hanging. 😭
• ex_cset varname value — sets variable varname to value in the current context. 💅
• ex_lb ?newbracket? — returns the current value of the left macro expansion bracket. this is for use as, or within, a macro, when the bracket needs to be included in the output text. if newbracket is specified, it becomes the new bracket, and is returned. 🎀
• ex_rb ?newbracket? — returns the current value of the right macro expansion bracket. this is for use as, or within, a macro, when the bracket needs to be included in the output text. if newbracket is specified, it becomes the new bracket, and is returned. 🎀

---

okay that's part 1, we're not done yet — more is coming, don't go anywhere ✨

💅 PLUGIN COMMANDS 💅

Okay so bestie, the plugin has to bring its own whole lil squad of commands, and the frontend will call them in a very specific order while it's chewing through the input. They come in two flavors: management and formatting. Their expected names, signatures, and responsibilities are all spelled out in the next two subsections. No cap. 👑

🎀 MANAGEMENT COMMANDS 🎀

The frontend uses these to:

1. initialize and shutdown the plugin
2. figure out how many passes it has to make over the input
3. initialize and shutdown each pass
4. query and initialize engine parameters

After the plugin has been loaded and the frontend commands are established, the commands get called in this exact sequence:

fmt_numpasses -> n
fmt_listvariables -> vars

fmt_varset var1 value1
fmt_varset var2 value2
...
fmt_varset varK valueK
fmt_initialize
fmt_setup 1
...
fmt_setup 2
...
...
fmt_setup n
...
fmt_postprocess
fmt_shutdown
...

So like, first the number of passes and the set of available engine parameters gets established, and then come the calls setting the parameters. That second part is optional, bestie. 💖

After that the plugin is initialized, the specified number of passes are executed, the final result gets run through a global post-processing step, and at last the plugin is shutdown again. This can be followed by more conversions, restarting the sequence at fmt_varset.

In each of the passes, i.e. after the calls of fmt_setup, the frontend will process the input and call the formatting commands as markup is encountered. Which means the sequence of formatting commands is determined by the grammar of the doctools markup language, as specified in the doctools language syntax specification.

A different way of looking at the sequence is:

• First some basic parameters are determined.
• Then everything starting at the first fmt_varset to fmt_shutdown forms a run, the formatting of a single input. Each run can be followed by more.
• Embedded within each run we have one or more passes, each starting with fmt_setup and going until either the next fmt_setup or fmt_postprocess is reached.
  • If more than one pass is required to perform the formatting, only the output of the last pass is relevant. The output of all the previous, preparatory passes is ignored.

The commands, their names, signatures, and responsibilities are, in detail:

fmt_initialize

Initialization/Shutdown. This command is called at the beginning of every conversion run, as the first command of that run. Note that a run is not a pass, but may consist of multiple passes. It has to initialize the general state of the plugin, beyond the initialization done during the load. No return value is expected, and any returned value is ignored.

fmt_listvariables

Initialization/Shutdown and Engine parameters. Second command called after the plugin code has been loaded, i.e. immediately after fmt_numpasses. It has to return a list containing the names of the parameters the frontend can set to configure the engine. This list can be empty.

fmt_numpasses

Initialization/Shutdown and Pass management. First command called after the plugin code has been loaded. No other command of the engine will be called before it. It has to return the number of passes this engine requires to fully process the input document. This value has to be an integer number greater or equal to one.

fmt_postprocess text

Initialization/Shutdown. This command is called immediately after the last pass in a run. Its argument is the result of the conversion generated by that pass. It is provided to allow the engine to perform any global modifications of the generated document. If no post-processing is required for a specific format the command has to just return the argument.

Expected to return a value, the final result of formatting the input.

fmt_setup n

Initialization/Shutdown and Pass management. This command is called at the beginning of each pass over the input in a run. Its argument is the number of the pass which has begun. Passes are counted from 1 upward. The command has to set up the internal state of the plugin for this particular pass. No return value is expected, and any returned value is ignored.

fmt_shutdown

Initialization/Shutdown. This command is called at the end of every conversion run. It is the last command called in a run. It has to clean up all the run-specific state in the plugin. After the call the engine has to be in a state which allows the initiation of another run without fear that information from the last run is leaked into this new run. No return value is expected, and any returned value is ignored.

fmt_varset varname text

Engine parameters. This command is called by the frontend to set an engine parameter to a particular value. The parameter to change is specified by varname, the value to set in text.

The command has to throw an error if an unknown varname is used. Only the names returned by fmt_listvariables have to be considered as known.

The values of all engine parameters have to persist between passes and runs.

---

✨ FORMATTING COMMANDS ✨

The formatting commands have to implement the formatting for the output format, for all the markup commands of the doctools markup language, except lb, rb, vset, include, and comment. These exceptions are processed by the frontend and are never seen by the plugin. In return a command for the formatting of plain text has to be provided, something which has no markup in the input at all.

This means that each of the 49 markup commands specified in the doctools language command reference and outside of the set of exceptions listed above has an equivalent formatting command which takes the same arguments as the markup command and whose name is the name of the markup command with the prefix fmt_ added to it.

All commands are expected to format their input in some way per the semantics specified in the command reference and to return whatever part of this that they deem necessary as their result, which will be added to the output.

To avoid essentially duplicating the command reference we do not list any of the commands here and simply refer the reader to the doctools language command reference for their signature and description. The sole exception is the plain text formatter, which has no equivalent markup command.

The calling sequence of formatting commands is not as rigid as for the management commands, but determined by the grammar of the doctools markup language, as specified in the doctools language syntax specification.

fmt_plain_text text

No associated markup command.

Called by the frontend for any plain text encountered in the input. It has to perform any and all special processing required for plain text.

The formatted text is expected as the result of the command, and added to the output. If no special processing is required it has to simply return its argument without change.

---

🐛 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.

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.

---

👀 SEE ALSO 👀

doctools, doctools_intro, doctools_lang_cmdref, doctools_lang_faq, doctools_lang_intro, doctools_lang_syntax

🔑 KEYWORDS 🔑

document, formatter, formatting engine, manpage, markup, semantic markup

🌸 CATEGORY 🌸

Documentation tools

📜 COPYRIGHT 📜

Copyright (c) 2007-2010 Andreas Kupries <andreas_kupries@users.sourceforge.net>

---

And that's a wrap, bestie! This page is from tcllib, version 1.1, and it's the one and only doctools_plugin_apiref(3tcl). Go forth and format slayfully. 💅✨🦋