docidx_lang_intro(3tcl)
π docidx_lang_intro(3tcl) β the docidx language intro, bestie edition π
okay so this is docidx_lang_intro, a page living in the Documentation tools section of the manual, and it's literally your cozy lil doorway into the docidx markup language. welcome, you're gonna slay π«Ά
β¨ NAME β¨
docidx_lang_intro β docidx language introduction. that's it, that's the whole name. iconic.
πΈ DESCRIPTION πΈ
So this document? It's an informal introduction to version 1 of the docidx markup language, and it teaches you by throwing a whole bunch of examples at you. no cap, that's the whole method. After you read this, a writer should be ready to understand the two parts of the formal specification, which are:
- the docidx language syntax specification, and
- the docidx language command reference.
Two halves, one glorious whole. π
π FUNDAMENTALS π
docidx markup is quite similar to doctools markup β like, cousins energy β but in the broadest terms possible there is one key difference. An index consists essentially only of markup commands, with no plain text interspersed between them, except for whitespace. that's the vibe check right there.
Each markup command is a Tcl command surrounded by a matching pair of [ and ]. Inside of these delimiters the usual rules for a Tcl command apply with regard to word quotation, nested commands, continuation lines, etc. I.e.
... [key {markup language}] ...
... [manpage thefile \
{file description}] ...
see how the second one does that little line-continuation backslash? main character behavior, honestly.
π¦ BASIC STRUCTURE π¦
The most simple document which can be written in docidx is
[index_begin GROUPTITLE TITLE]
[index_end]
Not very useful, but valid. and it also shows us that all docidx documents consist of only one part, where we will list all keys and their references. one part, one job, we love a focused queen.
A more useful index will contain at least keywords, or short 'keys', i.e. the phrases which were indexed. So:
[index_begin GROUPTITLE TITLE]
[key markup]
[key {semantic markup}]]
[key {docidx markup}]
[key {docidx language}]
[key {docidx commands}]
[index_end]
In the above example the command key is used to declare the keyword phrases we wish to be part of the index.
However a truly useful index does not only list the keyword phrases, but will also contain references to documents associated with the keywords. Here is a made-up index for all the manpages in the module base64:
[index_begin tcllib/base64 {De- & Encoding}]
[key base64]
[manpage base64]
[key encoding]
[manpage base64]
[manpage uuencode]
[manpage yencode]
[key uuencode]
[manpage uuencode]
[key yEnc]
[manpage yencode]
[key ydecode]
[manpage yencode]
[key yencode]
[manpage yencode]
[index_end]
In the above example the command manpage is used to insert references to documents, using symbolic file names, with each command belonging to the last key command coming before it. so like, a manpage follows its key like a duckling follows its mama. π£
The other command to insert references is url. In contrast to manpage it uses explicit (possibly format-specific) urls to describe the location of the referenced document. As such this command is intended for the creation of references to external documents which could not be handled in any other way. it's giving "for when nothing else fits" and honestly, respect.
π ADVANCED STRUCTURE π
In all previous examples we fudged a bit regarding the markup actually allowed to be used before the index_begin command opening the document. yeah we were being sneaky, sorry bestie π
Instead of only whitespace the two templating commands include and vset are also allowed, to enable the writer to either set and/or import configuration settings relevant to the table of contents. I.e. it is possible to write
[include FILE]
[vset VAR VALUE]
[index_begin GROUPTITLE TITLE]
...
[index_end]
Even more important, these two commands are allowed anywhere where a markup command is allowed, without regard for any other structure.
[index_begin GROUPTITLE TITLE]
[include FILE]
[vset VAR VALUE]
...
[index_end]
The only restriction include has to obey is that the contents of the included file must be valid at the place of the inclusion. I.e. a file included before index_begin may contain only the templating commands vset and include, a file included after a key may contain only manape or url references, and other keys, etc. so it's not "anything goes," it's "anything goes in the right spot." location location location, babe. π
π ESCAPES π
Beyond the 6 commands shown so far we have two more available. However their function is not the marking up of index structure, but the insertion of characters, namely [ and ]. These commands, lb and rb respectively, are required because our use of [ and ] to bracket markup commands makes it impossible to directly use [ and ] within the text. the brackets are doing double duty and honestly they're booked and busy. π
Our example of their use are the sources of the last sentence in the previous paragraph, with some highlighting added.
...
These commands, [cmd lb] and [cmd lb] respectively, are required
because our use of [lb] and [rb] to bracket markup commands makes it
impossible to directly use [lb] and [rb] within the text.
...
π yes, that really is [cmd lb] twice in there. we are reporting what the original says, character for character. no editing the queen's receipts.
β FURTHER READING β
Now that this document has been digested the reader, assumed to be a writer of documentation, should be fortified enough to be able to understand the formal docidx language syntax specification as well. you ate this page, now go eat the spec. π₯
From here on out the docidx language command reference will also serve as the detailed specification and cheat sheet for all available commands and their syntax. cheat sheet!! the way that it's both a spec AND a cheat sheet, we love a multitasker. π
To be able to validate a document while writing it, it is also recommended to familiarize oneself with Tclapps' ultra-configurable dtp. ultra-configurable. say it with me.
On the other hand, docidx is perfectly suited for the automatic generation from doctools documents, and this is the route Tcllib's easy and simple dtplite goes, creating an index for a set of documents behind the scenes, without the writer having to do so on their own. behind the scenes? that's giving backstage pass energy, we love a tool that just handles it. π§
π BUGS, IDEAS, FEEDBACK π
This document, and the package it describes, will undoubtedly contain bugs and other problems. ngl, inevitable, everything has a lil something. 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. ideas are welcome!! 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. left-most button, bestie. don't miss it. π
π SEE ALSO π
docidx_introdocidx_lang_cmdrefdocidx_lang_syntax
π KEYWORDS π
docidx commands, docidx language, docidx markup, docidx syntax, markup, semantic markup
πΈ CATEGORY πΈ
Documentation tools
π COPYRIGHT π
Copyright (c) 2007-2009 Andreas Kupries <andreas_kupries@users.sourceforge.net>
and that's the whole page, bestie!! β¨ this one's from tcllib, version 1.0, and yes, we're still out here in section 3tcl with the docidx_lang_intro(3tcl) girlies. go write an index, you're gonna be so good at it. π¦π
π¦ where this page comes from
- debian bookworm: tcllib 1.21+dfsg-1 Β· BSD
- debian trixie: tcllib 2.0+dfsg-4 Β· Tcl
- ubuntu jammy: tcllib 1.20+dfsg-1 Β· BSD
- ubuntu noble: tcllib 1.21+dfsg-1 Β· BSD
- ubuntu questing: tcllib 2.0+dfsg-4
- ubuntu resolute: tcllib 2.0+dfsg-5 Β· Tcl
- ubuntu stonking: tcllib 2.0+dfsg-6 Β· Tcl
- Copyright (c) 2007-2009 Andreas Kupries <andreas_kupries@users\&.sourceforge\&.net>
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms