A tool to generate documentation about Lisp projects through an HTML template.
Table of Contents
About Staple
Staple is a documentation system. It provides you with a way to generate standalone documentation accumulated from various sources such as readmes, documentation files, and docstrings.
How To
The most trivial manner in which to use staple is to simply run it and let its inference mechanism figure out how to document your system. You can do that like so:
(staple:generate :my-system)
For best immediate results you should not load your system before you load Staple, so that Staple can record the packages the system defines as it is being loaded. If you later customise the documentation and set the packages explicitly, you don't have to watch out for that anymore, though. The documentation should land in a subdirectory called doc
within the system's source directory. For ad-hoc usage you can change some of the behaviour through keyword arguments:
:output-directory
The base directory in which documentation files are stored.:images
A list of paths to image files that might be used in the documentation. The first image is used as the project's logo.:documents
A list of documents for which to generate documentation pages. This usually refers to things likeREADME.md
and such. Typically you would only have multiple of these if you have translated the documentation into different languages. In that case, Staple will create an index page for each language individually.:page-type
The class to use for pages. See the sections below.:template
The template file to use. If you want to customise what the documentation pages look like, you might want to change this to one of your own.:if-exists
What to do if the output file already exists (see open).:compact
Whether to compact the HTML files by trimming extraneous whitespace. Activated by default.:packages
The packages that should be included in the definitions index.:subsystems
A list of subsystems that are related to this primary system and should be included in the generation.
However, if you change any of these options, you will likely want to persist them somehow. The best way to do this is to use Staple's customisation mechanism. See the sections below for that.
You may also be interested in Staple's server system, which gives you a live documentation browser for all systems currently loaded in your Lisp image.
Concepts
Staple organises itself around project
s and page
s. Every mechanism in it is an extension of those two concepts.
Projects
Projects represent a, well, project. This is distinct from an ASDF system, as a project might encompass multiple systems. Similarly, an ASDF system fed to generate
might generate documentation for multiple ASDF systems at once. While a project might represent multiple systems, it is always identified by at least one "primary" system.
In order to get the project for a primary system, you can use find-project
. This will return NIL if no specific project is defined for a system. In that case you may also use infer-project
to let Staple try and figure out a project for the system automatically.
Each project is composed of a number of pages. When a project is generate
d, each of its pages
are generated as well, producing the actual output of the project.
Pages
A page represents an output that should be generated as part of a project. Typically this will be some kind of file, like an HTML document. A page has a specific language
and a title
. Pages with the same title should represent the same page, but in different languages. This allows you to write multilingual documentation. More on that later.
All you can do with a page, aside from inspecting its language, title, and output
, is to generate
it. For anything more advanced, you should have a look at its subclasses:
input-page
This is a primitive subclass of the page that denotes some kind of input
that is being transformed when the page is generated. It should be used for anything that bases its output on some kind of input file or stream.
static-page
This page simply copies the input to the output verbatim, providing a way to define static files such as images and so forth. Since images and such resources are not really "pages" per se, this might be a strange fit, but by simply leaving the title NIL
, you can use the same mechanisms regardless.
compiled-page
Compiled pages use Staple's compile-source
mechanism, which translates source in some other format like Markdown into HTML. By default only text and HTML itself is supported, but you can trivially add other formats, or use the staple-markdown
system to add Markdown support automatically.
templated-page
This kind of page uses the Clip system to perform a template expansion. If you want to use this kind of page, you should subclass it and add a method on template-data
to supply the necessary data to the Clip template. See Clip for further information.
definitions-index-page
Often times you'll want to include a definitions index alongside the main documentation content. THis page adds additional support for this by including a list of packages
to define, and several methods to aid in formatting the definitions, such as format-documentation
, resolve-source-link
, definition-wanted-p
, and definitions
. Note that this is a subclass of templated-page
, meaning that if you want a definitions index, but don't want to use Clip, you'll need to do some work of your own.
system-page
This page adds some additional convenience when dealing with pages that document a specific ASDF system.
simple-page
Finally, the simple page is used for inferred projects and offers a base page for easy customisation. It provides sensible defaults for definition inclusion, template data, and so forth.
Customisation
Customising Staple should happen through a file called staple.ext.lisp
within your primary system's root source directory. This file is automatically loaded by Staple when the system is generated, making it convenient to add extra functionality.
There's two ways in which to customise how Staple generates the documentation for your system. You can either define your own project manually for maximum control, or influence the inference mechanism for some quick and easy changes.
Custom Projects
Customising projects is easy to explain, as it simply involves adding a method to find-project
specialising on your system's name that returns the readily made project instance.
(defmethod staple:find-project ((system (eql (asdf:find-system :my-system))) &key)
#|.. create project ..|#)
See the documentation for the different kinds of pages to see what you can do with them. One thing you should always respect is the :output-directory
keyword argument, which should provide the root directory in which the documentation is stored. You can find a good default using the output-directory
function on your system.
You should still read the following sections, as they will show examples on how to customise pages and what kinds of functions there are to influence behaviour so that you don't necessarily need to write everything from scratch unless you want to.
Custom Inference
As mentioned in the How To section above, you can persist the different options you can pass to generate by changing the project inference. The following functions are called to determine the default values for the respective keyword arguments:
In order to override these, just write a method specialising on your system:
(defmethod staple:template ((system (eql (asdf:find-system :my-system))))
(asdf:system-relative-pathname system #p"my-template.ctml"))
Some properties like the way documentation and docstrings are formatted require changing the way pages behave. For that, you can override the page-type
similar to the above code snippet, and implement a custom page subclass as illustrated in the next section.
Custom Pages
By subclassing simple-page
, you can customise all sorts of behaviours.
(defclass my-page (staple:simple-page) ())
Following are a few examples for things one might frequently want to change about the default behaviour of a page. If you are customising project inference, you can use page-type
to use this page:
(defmethod staple:page-type ((system (eql (asdf:find-system :my-system))))
'my-page)
Changing Which Definitions are Shown
(defmethod staple:definition-wanted-p ((_ definitions:method) (__ my-page)) T)
(defmethod staple:definition-wanted-p ((_ definitions:compiler-macro) (__ my-page)) T)
(defmethod staple:definition-wanted-p ((_ definitions:macro) (__ my-page)) NIL)
This will show methods and compiler-macros, but hide macros. By default all definitions for external symbols are shown except for methods, packages, compiler-macros, and declarations.
Including Additional Definitions
(defmethod staple:definitions ((page my-page) package)
(append (definitions:find-definitions 'cl:if)
(call-next-method)))
This forces the definitions for cl:if
to be included with the rest of the definitions for the packages of the page.
Changing Source Links
(defmethod staple:resolve-source-link (source (page my-page))
(format NIL "http://someplace/view-file/~a#line-~a"
(make-path-relative-somehow (getf source :file))
(getf source :row)))
Note that by default, if you set the :homepage
property in your ASDF system definition to a GitHub or GitLab project URL, it will try to automatically compute the URL to GitHub's or GitLab's file viewer.
Changing Docstring Formatting
(defmethod staple:format-documentation ((docstring string) (page my-page))
(let ((*package* (first (staple:packages page))))
(staple:markup-code-snippets-ignoring-errors
(staple:compile-source docstring :markdown))))
This will parse the docstring as Markdown and cross-reference all code snippets. Make sure to also load the staple-markdown
system in your extension file.
Changing Document Formatting
(defmethod staple:compile-source ((document pathname) (page my-page))
(staple:compile-source document :text))
This will force the document to be parsed as raw text.
Changing the Filename
(defmethod staple:filename ((page my-page))
(make-pathname :name "foo" :type "html"))
This will force the file name of all pages to be foo.html
.
Changing or Adding Template Data
(defmethod staple:template-data append ((page my-page))
(list :title "My Title"
:generation-time (get-universal-time)))
Due to the append
method-combination and the way getf
works, this will override the :title
value, and add the new :generation-time
value which can now be referenced from the template.
Changing Generation Behaviour
(defmethod staple:generate :after ((page my-page) &key)
(format *debug-io* "~& Generated ~a.~%" page))
This adds a method that is called once the generation has completed, and simply prints a status message saying as much. You can use all the usual tricks of the standard method combination to customise things to your heart's content.
Custom Templates
Writing a custom template is mostly a question of writing an HTML document that you want, and then filling in the necessary Clip attributes to add the data in the right spots. Figuring this out should be pretty trivial if you have a look at the existing default template and the Clip documentation
An Example Customisation File
This is a simple example customisation file that changes the inferred project to use a custom markup syntax and package list.
(asdf:load-system :staple-markdown)
(defclass my-page (staple:simple-page) ())
(defmethod staple:page-type ((system (eql (asdf:find-system :my-system))))
'my-page)
(defmethod staple:packages ((system (eql (asdf:find-system :my-system))))
(mapcar #'find-package '(:my-system :my-system-other)))
(defmethod staple:format-documentation ((docstring string) (page my-page))
(let ((*package* (first (staple:packages page))))
(staple:markup-code-snippets-ignoring-errors
(staple:compile-source docstring :markdown))))
Custom Global Definitions
Staple has support for documenting arbitrary definition types aside from the standard top level definition types that Common Lisp exposes. This is done through the Definitions library. Please see its documentation on how to add custom definitions. You can write this extra glue code into your staple.ext.lisp
file along with all the other Staple customisations. When a new definition type is defined, Staple will automatically try to find it and include it in your simple-page
s. If you would like to be more selective, see definition-wanted-p
above.
Also of interest are definition-id
, definition-order
, and definition-importance
, which control the page anchors and order of appearance of definitions in an index.
Github Actions
You can generate your documentation with Staple through a Github Action automatically, using a workflow file like this:
name: documentation
on:
push:
branches:
- main
permissions:
pages: write
id-token: write
jobs:
publish:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v1
- uses: shinmera/staple@v2.0.0
with:
gh-pages: true
dist: http://dist.shirakumo.org/shirakumo.txt
The gh-pages
argument means it'll try to push to your Github Pages automatically. If you disable that, you'll have to make sure to upload or otherwise distribute the documentation yourself. The dist
argument lets you include an additional Quicklisp dist, if your project needs extra dependencies to be loaded. Other inputs you can pass to the action are:
System Information
Definition Index
-
STAPLE
- ORG.SHIRAKUMO.STAPLE
No documentation provided.-
EXTERNAL SPECIAL-VARIABLE *DEFAULT-TEMPLATE*
Pathname to the default Clip template used for simple pages. See SIMPLE-PAGE
-
EXTERNAL SPECIAL-VARIABLE *DOCUMENT-PATTERNS*
A list of regular expression patterns that recognise document files. An expression in this list should match the filename of a file that denotes a documentation body file.
-
EXTERNAL SPECIAL-VARIABLE *IMAGE-PATTERNS*
A list of regular expression patterns that recognise image files. An expression in this list should match the filename of a file that denotes an image file.
-
EXTERNAL SPECIAL-VARIABLE *LOAD-PROHIBITED-SYSTEMS*
A list of ASDF:SYSTEM instances that should not be loaded for extensions. This is a curated list of special systems that cause problems when being loaded as part of the LOAD-EXTENSION mechanism. See LOAD-EXTENSION
-
EXTERNAL SPECIAL-VARIABLE *PAGE*
-
EXTERNAL CLASS COMPILED-PAGE
A compiled page that is created by translating some input file. In order to handle the translation, COMPILE-SOURCE is used. The output of COMPILE-SOURCE may be a PLUMP:NODE, a STRING, or an (unsigned-byte 8) vector. In the case of a PLUMP:NODE, the node is first compressed using COMPACT if the :COMPACT argument to GENERATE is non-NIL (default). See INPUT-PAGE See COMPILE-SOURCE
-
EXTERNAL CLASS DEFINITIONS-INDEX-PAGE
Superclass for pages that include a definitions index. See PACKAGES See FORMAT-DOCUMENTATION See RESOLVE-SOURCE-LINK See DEFINITION-WANTED-P See DEFINITIONS
-
EXTERNAL CLASS INPUT-PAGE
-
EXTERNAL CLASS PAGE
Base class for all pages that can be generated as part of a project. A page represents a single, well, page within the documentation for a particular project. It should only produce a single output, which is typically a file. A page should, if possible, only contain text in a single language. This primary language is indicated by the page's LANGUAGE slot and defaults to "en" for English. If the output is a pathname, the behaviour on existing output may be specified through the :IF-EXISTS argument to GENERATE, by default set to :ERROR. See PROJECT See TITLE See LANGUAGE See OUTPUT See GENERATE
-
EXTERNAL CLASS PROJECT
Superclass for a documentation project. A project encapsulates all documentation for a library or program. Typically this is expressed by a number of PAGEs that will create the expected documentation files when the project is GENERATEd. The OUTPUT of a project represents the root directory of all output data. It is used to figure out relative paths between pages and resources. See OUTPUT See PAGE See PAGES See GENERATE
-
EXTERNAL CLASS SIMPLE-PAGE
A simple page to base documentation on. Simple-pages are the preferred pages to use for inferred systems. They provide a convenient all-in-one package for a definitions index and a documentation body. A single "document" makes up the main body of the page and should provide the primary documentation of the system or project. The document is transformed by COMPILE-SOURCE, which by default will automatically parse it from file and mark up code snippets within it. If the OUTPUT pathname passed as initarg to this class is missing the name and type, then the pathname is augmented using FILENAME of the page. See *DEFAULT-TEMPLATE* See DOCUMENT See IMAGES See FILENAME See SYSTEM-PAGE See COMPILE-SOURCE
-
EXTERNAL CLASS SIMPLE-PROJECT
-
EXTERNAL CLASS STATIC-PAGE
A static page that simply copies its input to its output. This is useful for static files such as images and other resources. See INPUT-PAGE
-
EXTERNAL CLASS SYSTEM-PAGE
Superclass for pages that represent and ASDF system. This system will compute several properties automatically by using the ASDF metadata: if the :PACKAGES are not given, they are computed from calling PACKAGES on the system object. When a source link is resolved and the project's homepage resides on GitHub or GitLab, it will try to guess a link to the GitHub/GitLab repository's viewer of the source file. See SYSTEM See DEFINITIONS-INDEX-PAGE
-
EXTERNAL CLASS TEMPLATED-PAGE
Superclass for pages that are templated using Clip. The template that Clip is run on is the INPUT of the page. The template arguments are computed using the TEMPLATE-DATA generic function. The output of the page is compressed using COMPACT if the :COMPACT argument to GENERATE is non-NIL (default). See INPUT-PAGE See TEMPLATE-DATA
-
EXTERNAL CONDITION NO-KNOWN-OUTPUT-DIRECTORY
Error signalled when no known output directory is available for a system. See SYSTEM See INFER-PROJECT
-
EXTERNAL TYPE-DEFINITION STREAM-DESIGNATOR
A type representing all possible values to be used with ENSURE-STREAM. See ENSURE-STREAM
-
EXTERNAL FUNCTION ABSOLUTE-SOURCE-LOCATION
- SOURCE-LOCATION
Translates the given Definitions source-location into an absolute one. This will read the source file to determine the absolute row/line and col/char pointed at by the source-location. It returns another plist of the following keys: :FILE --- The same as in the input. :OFFSET --- The absolute file-position offset. :ROW --- The row/line of the offset. :COL --- The col/char of the offset. Returns NIL if the file cannot be found, the source-location is NIL, or the file cannot be parsed. See SKIP-TO-SOURCE-FORM
-
EXTERNAL FUNCTION ENSURE-PACKAGE
- PACKAGE
Turns the given thing into a CL:PACKAGE. If the thing cannot be coerced, an error is signalled.
-
EXTERNAL FUNCTION ENSURE-PACKAGE-DEFINITION
- PACKAGE
Turns the given thing into a DEFINITIONS:PACKAGE. If the thing cannot be coerced, an error is signalled.
-
EXTERNAL FUNCTION EXTRACT-LANGUAGE
- STRING
Attempts to find a valid two or three-letter language code in the string. If a code can be found, two values are returned: the code itself and the list of names for the language the code points to. See LANGUAGE-CODES:NAMES
-
EXTERNAL FUNCTION FIND-DEFINITIONS-FOR-IDENTIFIER
- NAME
- &KEY
- PACKAGE
- TYPE
Attempts to find all definitions for the given symbol identifier. The symbol is given in two parts -- as its name, and package. The list of returned definitions may optionally be filtered by the given type argument. If no package is given, the definitions are attempted to be found in the packages stored in *PAGE*, or the CL package. See *PAGE* See PACKAGES See DEFINITIONS:FIND-DEFINITIONS
-
EXTERNAL FUNCTION FIND-FILES
- DIRECTORY
- PATTERNS
- &KEY
- MAX-DEPTH
- EXCLUDE
Find all files in the directory tree that match one of the patterns. The patterns should be regular expressions suitable for CL-PPCRE. They are matched against the file-namestrings of the files in the directory tree. See DO-DIRECTORY-TREE
-
EXTERNAL FUNCTION LOAD-EXTENSION
- SYSTEM
Loads the extension file of the system. This ensures that all Staple extensions and customisations that the system might need are present and loaded when the documentation is generated. It proceeds as follows: 1. The argument is coerced to an ASDF:SYSTEM 2. If the system was already involved in a LOAD-EXTENSION call within this call tree, NIL is returned immediately. 3. Otherwise the system is loaded via ASDF:LOAD-SYSTEM, with warnings and standard-output muffled. 4. For each dependency registered for the system, LOAD-EXTENSION is called again to ensure dependant extensions are loaded first. 5. The EXTENSION-FILE, if present, is LOADed. 6. The system is returned. See ASDF:LOAD-SYSTEM See CL:LOAD
-
EXTERNAL FUNCTION LOAD-SYSTEM-QUIETLY
- SYSTEM
Loads the given ASDF:SYSTEM quietly. This muffles warnings and suppresses *standard-output*. See ASDF:LOAD-SYSTEM
-
EXTERNAL FUNCTION MARKUP-CODE-BLOCK
- NODE
Transforms the node's content treating it as a code block. Only the textual contents of the node are inspected, any other kinds of tag that may be a child to the block will be removed by this. All definitions that are recognised in this that have a result for XREF will be marked up by an <a> tag with the class "xref". Note that the value of *PACKAGE* matters for the parsing of the code blocks, as a full READ and walk is performed on it to find symbols and their usage in the code snippet. Note also that if invalid code or non-lisp code is encountered an error may be signalled by the reader. See XREF See STAPLE-CODE-PARSER:PARSE See STAPLE-CODE-PARSER:PARSE-RESULT->DEFINITION-LIST
-
EXTERNAL FUNCTION MARKUP-CODE-REFERENCE
- NODE
Transforms the node's content treating it as a definition reference. Only the textual contents of the node are inspected, any other kinds of tag that may be a child to the block will be removed by this. This simply uses XREF on the textual content and if a result is returned, inserts an <a> tag with the class "xref" to provide the link. See XREF
-
EXTERNAL FUNCTION MARKUP-CODE-SNIPPETS
- HTML
Attempts to mark up the code snippets in the given HTML text. This looks for <code> tags within the given HTML and will try to automatically insert xref links. It performs transformations as follows: Each <code> tag that is direct child to a <pre> tag is transformed using MARKUP-CODE-BLOCK, with the intention that the <code> element contains full code snippets. <code> tags without a <pre> parent will be transformed using MARKUP-CODE-REFERENCE, with the idea that these will only contain single symbol names that represent direct references to definitions. If an error occurs during the markup of a tag, a SKIP-TAG restart will be available to allow skipping that particular tag. The return value of this function is a PLUMP:NODE if the argument is also a PLUMP:NODE, and a STRING if the argument is either a STRING or a PATHNAME. See MARKUP-CODE-BLOCK See MARKUP-CODE-REFERENCE
-
EXTERNAL FUNCTION MARKUP-CODE-SNIPPETS-IGNORING-ERRORS
- HTML
Marks up the code snippets ignoring parts that fail during markup. See MARKUP-CODE-SNIPPETS
-
EXTERNAL FUNCTION MAYBE-LANG-DOCSTRING
- DEFINITION
- LANGUAGE
Attempts to find a docstring for the given definition in the given language. If the multilang-documentation system is loaded, then this consults MULTILANG-DOCUMENTATION:DOCUMENTATION using the DEFINITIONS:OBJECT and T as arguments, and alternatively the DEFINITIONS:DESIGNATOR and DEFINITIONS:TYPE. If either the system is not loaded, or it fails to return anything for both queries, it falls back to just returning the DEFINITIONS:DOCUMENTATION. See MULTILANG-DOCUMENTATION:DOCUMENTATION See DEFINITIONS:DOCUMENTATION
-
EXTERNAL FUNCTION PATHNAME-TYPE->TYPE
- TYPE
- &OPTIONAL
- ERRORP
Returns a keyword for the given pathname-type, if it is known. If ERRORP is non-NIL and no type can be found, an error is signalled. When used as a setf-place, the value should be a list of pathname-type strings that should be associated with the given type. Note that this is overriding, meaning that previous associations to the given type are removed. See COMPILE-SOURCE See DEFINE-SOURCE-COMPILER
-
EXTERNAL FUNCTION (SETF PATHNAME-TYPE->TYPE)
- TYPES
- TYPE
No documentation provided. -
EXTERNAL FUNCTION PREFERRED-DEFINITION
- DEFINITIONS
Returns the list sorted such that the most important, or preferred definitions, come first. See DEFINITION-IMPORTANCE
-
EXTERNAL FUNCTION PURIFY-ARGLIST
- ARGLIST
Purifies the given arguments list / lambda-list. This function is useful for presenting the user-interface part of a lambda-list. Thus it trims all extraneous information that the user of a function or macro does not need to know about. Specifically this does the following, depending on the current lambda-list-keyword in the arglist: REQUIRED --- The argument is purified recursively if it is a list, and retained verbatim otherwise. &OPTIONAL --- Only the variable name is retained. &KEY --- Only the variable's keyword-name is retained. &WHOLE --- The argument is removed. &ENVIRONMENT --- The argument is removed. &AUX --- The argument is removed.
-
EXTERNAL FUNCTION READ-FILE
- PATH
Reads the given file to a string and returns it.
-
EXTERNAL FUNCTION REMOVE-XREF-RESOLVER
- NAME
Removes the cross-reference resolver of the given name. See XREF-RESOLVER
-
EXTERNAL FUNCTION RESOLVE-XREF
- DEFINITION
Calls each cross-reference resolver with the definition until one returns a valid reference. See XREF-RESOLVER See DEFINE-XREF-RESOLVER
-
EXTERNAL FUNCTION SORT-DEFINITIONS
- DEFINITIONS
Sorts the list of definitions into a natural order. Definitions of different type are sorted by DEFINITION-ORDER. Definitions of the same type are sorted by STRING< using DEFINITIONS:NAME as the key. The sort is performed stably. See DEFINITION-ORDER
-
EXTERNAL FUNCTION URL-ENCODE
- THING
- &OPTIONAL
- EXTERNAL-FORMAT
Performs percent, or url-encoding of the string.
-
EXTERNAL FUNCTION XREF-RESOLVER
- NAME
Accessor to the cross-reference resolver of the given name. The resolver should be a function of one argument, a definition instance. It should return either NIL, or a URL string. Default xref-resolvers for the current page that's being generated, and the common-lisp package, are defined. It is useful to define addition resolvers if you have some kind of source of documentation that you would like to be able to link to. Resolvers allow an optional priority number to control in which order they're invoked. When reading the resolver, the priority is returned as the second value. See REMOVE-XREF-RESOLVER See DEFINE-XREF-RESOLVER See RESOLVE-XREF
-
EXTERNAL FUNCTION (SETF XREF-RESOLVER)
- FUNCTION
- NAME
- &OPTIONAL
- PRIORITY
No documentation provided. -
EXTERNAL GENERIC-FUNCTION COMPILE-SOURCE
- SOURCE
- TYPE
Compiles the source to a usable format, interpreting it as the given type. The following argument combinations have specifically defined behaviour: Source: Type: Explanation: -------------------------------------------------------------------- PATHNAME (EQL T) --- COMPILE-SOURCE is called again using the pathname's pathname-type as type argument. PATHNAME T --- COMPILE-SOURCE is called again using the contents of the file in string form as source argument. T STRING --- COMPILE-SOURCE is called again using the type returned by PATHNAME-TYPE->TYPE as the type argument. You should add methods to this function specialising on a particular source type to handle the translation appropriately. See PATHNAME-TYPE->TYPE See DEFINE-SOURCE-COMPILER
-
EXTERNAL GENERIC-FUNCTION CURRENT-COMMIT
- SYSTEM
No documentation provided. -
EXTERNAL GENERIC-FUNCTION DEFINITION-ID
- DEFINITION
Returns a string representing a unique ID for the given definition. This is useful for creating links and anchors for definitions in a document.
-
EXTERNAL GENERIC-FUNCTION DEFINITION-IMPORTANCE
- DEFINITION
Returns a number for the given definition, used to determine if one definition should receive precedence over another. By default, the following sorting is applied: DEFINITIONS:CALLABLE 30 DEFINITIONS:TYPE 20 DEFINITIONS:VARIABLE 10 DEFINITIONS:DEFINITION 0 DEFINITIONS:METHOD -10 See PREFERRED-DEFINITION
-
EXTERNAL GENERIC-FUNCTION DEFINITION-ORDER
- DEFINITION
Returns a number for the given definition, used for sorting. The higher the number, the earlier the definition should appear in the sorting. By default, the following sorting is applied: DEFINITIONS:PACKAGE 200 DEFINITIONS:CONSTANT 190 DEFINITIONS:SYMBOL-MACRO 180 DEFINITIONS:SPECIAL-VARIABLE 170 DEFINITIONS:VARIABLE 160 DEFINITIONS:CLASS 150 DEFINITIONS:CONDITION 140 DEFINITIONS:STRUCTURE 130 DEFINITIONS:TYPE-DEFINITION 120 DEFINITIONS:TYPE 110 DEFINITIONS:ACCESSOR 100 DEFINITIONS:FUNCTION 90 DEFINITIONS:GENERIC-FUNCTION 80 DEFINITIONS:METHOD 70 DEFINITIONS:COMPILER-MACRO 60 DEFINITIONS:MACRO 50 DEFINITIONS:SETF-EXPANDER 40 DEFINITIONS:CALLABLE 30 DEFINITIONS:METHOD-COMBINATION 20 DEFINITIONS:GLOBAL-DEFINITION 10 DEFINITIONS:DEFINITION 0 See SORT-DEFINITIONS
-
EXTERNAL GENERIC-FUNCTION DEFINITION-WANTED-P
- DEFINITION
- PAGE
This function should return T if the definition should be included in the page's definitions index. See DEFINITIONS-INDEX-PAGE
-
EXTERNAL GENERIC-FUNCTION DEFINITIONS
- PAGE
- PACKAGE
This function should return a list of applicable definitions for the given page and package. By default this will simply compute /all/ definitions in the package and only keeping wanted ones by DEFINITION-WANTED-P. The returned list of definitions is always sorted in the natural order as described by SORT-DEFINITIONS. See DEFINITION-WANTED-P See SORT-DEFINITIONS
-
EXTERNAL GENERIC-FUNCTION DOCUMENT
- OBJECT
Accessor for the document the simple-page will include in its body. This should be a pathname to a file that can be parsed by COMPILE-SOURCE. See SIMPLE-PAGE See COMPILE-SOURCE
-
EXTERNAL GENERIC-FUNCTION (SETF DOCUMENT)
- NEW-VALUE
- OBJECT
No documentation provided. -
EXTERNAL GENERIC-FUNCTION DOCUMENT-PACKAGE
- OBJECT
No documentation provided. -
EXTERNAL GENERIC-FUNCTION (SETF DOCUMENT-PACKAGE)
- NEW-VALUE
- OBJECT
No documentation provided. -
EXTERNAL GENERIC-FUNCTION DOCUMENTS
- SYSTEM
Returns a list of pathnames to documents relevant for the given system. By default this will attempt a heuristic by searching for files that can be parsed by PATHNAME-TYPE->TYPE, and match one of the *DOCUMENT-PATTERNS* within the system's source directory. You may add a method specialising on a particular system to change which documents are used for an inferred project. See PATHNAME-TYPE->TYPE See *DOCUMENT-PATTERNS* See INFER-PROJECT
-
EXTERNAL GENERIC-FUNCTION EXTENSION-FILE
- SYSTEM
Returns the Staple extension source file for the ASDF:SYSTEM. By default this is a file called "staple.ext.lisp" within the system's source directory. This function may return NIL to indicate that the system has no extension file. See ASDF:SYSTEM-SOURCE-DIRECTORY
-
EXTERNAL GENERIC-FUNCTION FILENAME
- PAGE
Returns a suitable pathname making up the filename of the page. By default for simple-pages this is the name "index" followed by the language code of the page, if the language is not :en or :eng, and the type "html". See SIMPLE-PAGE
-
EXTERNAL GENERIC-FUNCTION FIND-PROJECT
- PROJECT
- &KEY
- &ALLOW-OTHER-KEYS
Find and return the project for the given project designator. Typically the project designator will be an ASDF:SYSTEM. If you want to define a custom project for your system, you should add a method specialising on your system instance to this function and have it return the appropriately filled out project instance. By default this will first call LOAD-EXTENSION on the system, and will then call itself again if it can now find new methods specialising either on the system's instance or its name as a keyword. Otherwise it simply returns NIL. See LOAD-EXTENSION
-
EXTERNAL GENERIC-FUNCTION FORMAT-DOCUMENTATION
- DEFINITION
- PAGE
Formats the definition according to the page's preferences. This function should be called to retrieve fully formatted HTML to use as the documentation for a given definition on a page. By default this will call MAYBE-LANG-DOCSTRING on the definition and the page's language to retrieve the raw docstring, and then call FORMAT-DOCUMENTATION again with the docstring and the page. If a string is passed, it will by default parse it in the "See" style wherein each Line beginning with "See" is treated as a line indicating a source cross-reference. The rest of the line is interpreted as a designator for another definition and is turned into an xref link if possible. If you would prefer other documentation styles, you should add a method specialising on a custom page type, then use that page type in your project. See DEFINITIONS-INDEX-PAGE See MAYBE-LANG-DOCSTRING See XREF
-
EXTERNAL GENERIC-FUNCTION GENERATE
- PAGE
- &KEY
- IF-EXISTS
- COMPACT
- &ALLOW-OTHER-KEYS
Generate the outputs of the given object. The value returned by this function should be some kind of identifier of the outputs that were generated by the call to this function. In the case of a page, this will be the output file or result produced by the page. In the case of a project, this will typically be the project itself, and a list of the results from the pages it generated. If this function is called with something that isn't a project or page then the argument is treated as a potential ASDF:SYSTEM and is coerced to one by ASDF:FIND-SYSTEM. It will then try to find a project for the system by first consulting FIND-PROJECT, and then INFER-PROJECT. If both FIND-PROJECT and INFER-PROJECT fail, an error is signalled. Otherwise, GENERATE is called on the newly retrieved project. See PAGE See PROJECT See *PAGE* See FIND-PROJECT See INFER-PROJECT
-
EXTERNAL GENERIC-FUNCTION IMAGES
- OBJECT
Returns a list of pathnames to images relevant for the given system. By default this will attempt a heuristic by searching for files that match one of the *IMAGE-PATTERNS* within the system's source directory. You may add a method specialising on a particular system to change which images are used for an inferred project. See *IMAGE-PATTERNS* See INFER-PROJECT
-
EXTERNAL GENERIC-FUNCTION (SETF IMAGES)
- NEW-VALUE
- OBJECT
No documentation provided. -
EXTERNAL GENERIC-FUNCTION INFER-PROJECT
- PROJECT
- &KEY
- OUTPUT-DIRECTORY
- IMAGES
- DOCUMENTS
- PAGE-TYPE
- TEMPLATE
- PACKAGES
- SUBSYSTEMS
- &ALLOW-OTHER-KEYS
Attempts to infer a project suitable for the given ASDF:SYSTEM. By default this consults a variety of functions and attempts to build a suitable SIMPLE-PROJECT instance that should document the system. If you want to control how the documentation is generated, you may either specialise the functions INFER-PROJECT uses, or construct your own project entirely by specialising on FIND-PROJECT instead. INFER-PROJECT proceeds as follows: 1. If no :OUTPUT-DIRECTORY is given, it is found via OUTPUT-DIRECTORY. 2. If no :DOCUMENTS are given, they are found via DOCUMENTS. 3. If no :IMAGES are given, they are found via IMAGES. 4. If no :PAGE-TYPE is given, it is found via PAGE-TYPE. 5. If no :TEMPLATE is given, it is found via TEMPLATE. 6. If no :PACKAGES are given, they are found via PACKAGES. 7. If no :SUBSYSTEMS are given, they are found via SUBSYSTEMS. 8. If no output directory is known, a recoverable error of type NO-KNOWN-OUTPUT-DIRECTORY is signalled. You may use the USE-VALUE restart to provide a new output directory. 9. Each entry in the subsystems list may either be an ASDF system, or a list of an ASDF system and the same keyword arguments as above. The properties are inferred as follows: 9.1 If no :OUTPUT-DIRECTORY is given, a subdirectory by the name of the subsystem within the primary system's output directory is used. 9.2 If no :DOCUMENTS are given, they are found via DOCUMENTS. 9.3 If no :IMAGES are given, they are found via IMAGES, or the primary system's images are used. 9.4 If no :PAGE-TYPE is given, it is found via PAGE-TYPE, or the primary system's page-type is used. 9.5 If no :TEMPLATE is given, it is found via TEMPLATE, or the primary system's template is used. 9.6 If no :PACKAGES are given, they are found via PACKAGES. 9.7 If the subsystem's source directory is the same as the primary system's, and the list of documents are the same, the subsystem's document list is emptied to avoid the subsystem using documents intended for the primary system. 9.8 All documents for the subsystem are removed from the documents list for the primary system. 9.9 For each document for the subsystem, a page of page-type is constructed, passing the template as :INPUT, the output directory as :OUTPUT, the system as :SYSTEM, the document as :DOCUMENT, the list of images as :IMAGES, and the list of packages as :PACKAGES. 9.10. If the documents list is empty, a single page of page-type is constructed with the same arguments as before, except the :DOCUMENT being NIL. 9.11. For each pathname in the images list a page of type STATIC-PAGE is constructed that will copy the image file into the OUTPUT-DIRECTORY while preserving pathname name and type. 10. For each pathname in the documents list a page of page-type is constructed, passing the template as :INPUT, the output directory as :OUTPUT, the system as :SYSTEM, the document's pathname as :DOCUMENT, the list of images as :IMAGES, and the list of packages as :PACKAGES. 11. If the documents list is empty, a single page of page-type is constructed with the same arguments as before, except the :DOCUMENT being NIL. 12. For each pathname in the images list a page of type STATIC-PAGE is constructed that will copy the image file into the OUTPUT-DIRECTORY while preserving pathname name and type. 13. A SIMPLE-PROJECT instance is constructed and returned with those pages as the :PAGES argument. See OUTPUT-DIRECTORY See DOCUMENTS See IMAGES See PACKAGES See PAGE-TYPE See TEMPLATE See SUBSYSTEMS See *DEFAULT-TEMPLATE* See NO-KNOWN-OUTPUT-DIRECTORY See CL:USE-VALUE See STATIC-PAGE See SIMPLE-PROJECT
-
EXTERNAL GENERIC-FUNCTION INPUT
- OBJECT
Accessor to the input of the page. The input should be a STREAM-DESIGNATOR, meaning that it can be resolved to a stream via ENSURE-STREAM. Typically it will be a pathname pointing to the file from which the page's input should be ready. See INPUT-PAGE
-
EXTERNAL GENERIC-FUNCTION (SETF INPUT)
- NEW-VALUE
- OBJECT
No documentation provided. -
EXTERNAL GENERIC-FUNCTION LANGUAGE
- OBJECT
Accessor to the language of a page. The language should be a two or three-letter short-code that uniquely identifies the language as a keyword. See the ISO-639 language codes for all available options. See PAGE
-
EXTERNAL GENERIC-FUNCTION (SETF LANGUAGE)
- NEW-VALUE
- OBJECT
No documentation provided. -
EXTERNAL GENERIC-FUNCTION OUTPUT
- OBJECT
Accessor to the output of a page. The output should be a STREAM-DESIGNATOR, meaning that it can be resolved to a stream via ENSURE-STREAM. Typically it will be a pathname pointing to the file into which the page's contents should be stored. See PAGE
-
EXTERNAL GENERIC-FUNCTION (SETF OUTPUT)
- NEW-VALUE
- OBJECT
No documentation provided. -
EXTERNAL GENERIC-FUNCTION OUTPUT-DIRECTORY
- SYSTEM
Returns the output directory to which documentation for the given system should be output. By default this returns the "doc/" subdirectory within the system's source directory. You may add a method specialising on a particular system to change where the resulting content is stored for an inferred project. See ASDF:SYSTEM-SOURCE-DIRECTORY See INFER-PROJECT
-
EXTERNAL GENERIC-FUNCTION PACKAGE-SYSTEM
- PACKAGE
Returns the system associated with the package. This is typically the system that defines the package, if the package was recorded through Staple's package recording mechanism. If this automated detection is not smart enough, you may supply methods on this function to specify the correct system for a package. See CL:PACKAGE
-
EXTERNAL GENERIC-FUNCTION PACKAGES
- SYSTEM
Accessor to the list of packages associated with the instance. This will always return a list of PACKAGE instances, not package designators. If passed an ASDF:SYSTEM instance, it will return the list of packages that were either recorded explicitly for the system during loading, or were either inferred or explicitly set for the system. If passed a DEFINITIONS-INDEX-PAGE instance, it will return the list of packages that should be put into the index. For anything else it will try to coerce the argument to an ASDF:SYSTEM via ASDF:FIND-SYSTEM. See ASDF:SYSTEM See DEFINITIONS-INDEX-PAGE
-
EXTERNAL GENERIC-FUNCTION (SETF PACKAGES)
- PACKAGES
- SYSTEM
No documentation provided. -
EXTERNAL GENERIC-FUNCTION PAGE-SIBLINGS
- PAGE
No documentation provided. -
EXTERNAL GENERIC-FUNCTION PAGE-TYPE
- SYSTEM
Returns the type of the page that should be used for the given system's inferred project. By default this returns 'SIMPLE-PAGE You may add a method specialising on a particular system to change which page-type is used for an inferred project. See SIMPLE-PAGE See INFER-PROJECT
-
EXTERNAL GENERIC-FUNCTION PAGE-VARIANTS
- PAGE
No documentation provided. -
EXTERNAL GENERIC-FUNCTION PAGES
- PROJECT
-
EXTERNAL GENERIC-FUNCTION (SETF PAGES)
- NEW-VALUE
- OBJECT
No documentation provided. -
EXTERNAL GENERIC-FUNCTION PROJECT
- OBJECT
Accessor to the page's project. See PAGE
-
EXTERNAL GENERIC-FUNCTION (SETF PROJECT)
- NEW-VALUE
- OBJECT
No documentation provided. -
EXTERNAL GENERIC-FUNCTION RELATIVE-PATH
- TO
- FROM
Return the relative path from the second argument to the first. By default the following cases are handled: To: From: Explanation: -------------------------------------------------------------------- PATHNAME PATHNAME --- Computes the relative pathname. PAGE T --- Delegates using OUTPUT. T PAGE --- Delegates using OUTPUT. PROJECT T --- Delegates using OUTPUT. T PROJECT --- Delegates using OUTPUT. PAGE (EQL T) --- Delegates using PROJECT. See PATHNAME-UTILS:RELATIVE-PATH See OUTPUT See PROJECT See PAGE
-
EXTERNAL GENERIC-FUNCTION RESOLVE-SOURCE-LINK
- SOURCE
- PAGE
Resolve the link to a source file to a URI. The source should be either a definition or a source spec. In case of a definition, the function is called again with the source spec as computed by ABSOLUTE-SOURCE-LOCATION on DEFINITIONS:SOURCE-LOCATION. A source spec should be a plist of the following possible keys: :FILE --- An absolute pathname to the source file. Required. :ROW --- An optional row/line to which to point within the file. :COL --- An optional col/char to which to point within the line. By default this will try a "best effort" resolution, meaning relative links if the file's path is a subpath of the page's output. Otherwise it will fall back to a "file://" link. See DEFINITIONS:SOURCE-LOCATION See ABSOLUTE-SOURCE-LOCATION
-
EXTERNAL GENERIC-FUNCTION SUBSYSTEMS
- SYSTEM
Returns a list of systems that are related to the given system. By default this will find all ASDF systems whose name contains the given system's name as a prefix. You may add a method specialising on a particular system to change which subsystems are used for an inferred project. See INFER-PROJECT
-
EXTERNAL GENERIC-FUNCTION SYSTEM
- OBJECT
Accessor to the system the object is associated with. See SYSTEM-PAGE See NO-KNOWN-OUTPUT-DIRECTORY
-
EXTERNAL GENERIC-FUNCTION (SETF SYSTEM)
- NEW-VALUE
- OBJECT
No documentation provided. -
EXTERNAL GENERIC-FUNCTION TEMPLATE
- SYSTEM
Returns the pathname to a Clip template suitable for the given system. You may add a method specialising on a particular system to change which template is used for an inferred project. See INFER-PROJECT
-
EXTERNAL GENERIC-FUNCTION TEMPLATE-DATA
- PAGE
Returns the arguments to CLIP:PROCESS that should be used for the page. This should be a plistt containing the necessary data to compile the template. Note that this generic function uses the APPEND method- combination, meaning that you may add new keys by simply adding a new method to this function. The method combination uses :MOST-SPECIFIC-FIRST, and since plists short-circuit, you may also use a method to override keys that less-specific methods may have set. See TEMPLATED-PAGE
-
EXTERNAL GENERIC-FUNCTION TITLE
- OBJECT
Accessor to the title of a page. The title should be a very short, unique identifier for the page within the project. Pages that represent the same content but in different languages should have the same titles. The title of a page may be used as the name for a link to that page. See PAGE
-
EXTERNAL GENERIC-FUNCTION (SETF TITLE)
- NEW-VALUE
- OBJECT
No documentation provided. -
EXTERNAL GENERIC-FUNCTION XREF
- THING
- &OPTIONAL
- TYPE
Attempts to find a cross-reference URL for the given thing. The following default cases are handled: DEFINITIONS:DEFINITION --- RESOLVE-XREF is called directly. STRING --- The string is parsed by PARSE-SYMBOL, and if it represents a valid symbol, matching definitions are attempted to be found via FIND-DEFINITIONS-FOR-IDENTIFIER. The definitions are ranked according to PREFERRED-DEFINITION, and the first one cross-reference via RESOLVE-XREF that can be found is returned. The optional TYPE argument constrains the cross references to be of the given type of definition. See RESOLVE-XREF See PARSE-SYMBOL See FIND-DEFINITIONS-FOR-IDENTIFIER See PREFERRED-DEFINITION
-
EXTERNAL MACRO DEFINE-SOURCE-COMPILER
- TYPE
- &REST
- PATHNAME-TYPES
- INPUT
- &BODY
- BODY
Defines a new source compiler variant. This is a shorthand that sets the PATHNAME-TYPE->TYPE association and defines a new method on COMPILE-SOURCE to handle the conversion. Thus, the TYPE should be a keyword identifying the source type, and PATHNAME-TYPES should be an enumeration of known file types that are used for this kind of conversion. You may also leave this empty if you are defining a source type conversion that is not usually backed by explicit files. See PATHNAME-TYPE->TYPE See COMPILE-SOURCE
-
EXTERNAL MACRO DEFINE-XREF-RESOLVER
- NAME
- ARGS
- &BODY
- BODY
Defines a new cross-reference resolver function. The lambda-list should accept one required argument, the definition instance to find a cross-reference for. The name can be either a name for the resolver, or a list of name and priority number. See XREF-RESOLVER See REMOVE-XREF-RESOLVER See RESOLVE-XREF
-
EXTERNAL MACRO WITH-STREAM
- STREAM
- DESIGNATOR
- &REST
- ARGS
- &BODY
- BODY
Handles stream opening and closing, returning a useful value. Essentially this calls ENSURE-STREAM on the designator and the args. Upon unwinding, CLOSE is called on the stream. On successful exit of the body, STREAM-VALUE is returned. See ENSURE-STREAM See STREAM-VALUE