Next: Introduction, Previous: (dir), Up: (dir) [Contents][Index]
This is the staple Reference Manual, version 2.0.0, generated automatically by Declt version 3.0 "Montgomery Scott" on Tue Dec 22 15:07:21 2020 GMT+0.
| • Introduction | What staple is all about | |
| • Systems | The systems documentation | |
| • Files | The files documentation | |
| • Packages | The packages documentation | |
| • Definitions | The symbols documentation | |
| • Indexes | Concepts, functions, variables and data types |
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.
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 like README.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.
Staple organises itself around projects and pages. Every mechanism in it is an extension of those two concepts.
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 generated, each of its pages are generated as well, producing the actual output of the project.
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-pageThis 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-pageThis 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-pageCompiled 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-pageThis 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-pageOften 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-pageThis page adds some additional convenience when dealing with pages that document a specific ASDF system.
simple-pageFinally, 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.
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.
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.
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:
output-directorydocumentsimagespage-typetemplatepackagessubsystemsIn 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.
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)
(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.
(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.
(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.
(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.
(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.
(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.
(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.
(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.
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
By default Staple outputs the documentation into the source tree of your project. This will cause GitHub to index the HTML file and, depending on circumstances, think that your project is now primarily an HTML project. To fix this issue, you should mark the documentation as ignored for GitHub's indexer. You can do this by putting the following into a .gitattributes file at the repository root:
doc/ linguist-vendored
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))))
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-pages. 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.
Next: Files, Previous: Introduction, Up: Top [Contents][Index]
The main system appears first, followed by any subsystem dependency.
| • The staple system | ||
| • The staple-package-recording system | ||
| • The staple-code-parser system |
Next: The staple-package-recording system, Previous: Systems, Up: Systems [Contents][Index]
Nicolas Hafner <shinmera@tymoon.eu>
Nicolas Hafner <shinmera@tymoon.eu>
(:git "https://github.com/shinmera/staple.git")
zlib
A tool to generate documentation about Lisp projects through an HTML template.
2.0.0
staple.asd (file)
Next: The staple-code-parser system, Previous: The staple system, Up: Systems [Contents][Index]
Nicolas Hafner <shinmera@tymoon.eu>
Nicolas Hafner <shinmera@tymoon.eu>
(:git "https://github.com/shinmera/staple.git")
zlib
Collects information about packages being defined with an ASDF system.
1.0.1
staple-package-recording.asd (file)
recording.lisp (file)
Previous: The staple-package-recording system, Up: Systems [Contents][Index]
Nicolas Hafner <shinmera@tymoon.eu>
Nicolas Hafner <shinmera@tymoon.eu>
(:git "https://github.com/shinmera/staple.git")
zlib
A code parser tool for documentation markup
1.0.0
staple-code-parser.asd (file)
Files are sorted by type and then listed depth-first from the systems components trees.
| • Lisp files |
Next: The staple-package-recording․asd file, Previous: Lisp files, Up: Lisp files [Contents][Index]
staple.asd
staple (system)
Next: The staple-code-parser․asd file, Previous: The staple․asd file, Up: Lisp files [Contents][Index]
staple-package-recording.asd
staple-package-recording (system)
Next: The staple/package․lisp file, Previous: The staple-package-recording․asd file, Up: Lisp files [Contents][Index]
parser/staple-code-parser.asd
staple-code-parser (system)
Next: The staple/toolkit․lisp file, Previous: The staple-code-parser․asd file, Up: Lisp files [Contents][Index]
Next: The staple/xref․lisp file, Previous: The staple/package․lisp file, Up: Lisp files [Contents][Index]
package.lisp (file)
staple (system)
toolkit.lisp
Next: The staple/transform․lisp file, Previous: The staple/toolkit․lisp file, Up: Lisp files [Contents][Index]
toolkit.lisp (file)
staple (system)
xref.lisp
Next: The staple/code-format․lisp file, Previous: The staple/xref․lisp file, Up: Lisp files [Contents][Index]
xref.lisp (file)
staple (system)
transform.lisp
*pathname-type-type-map* (special variable)
Next: The staple/clip․lisp file, Previous: The staple/transform․lisp file, Up: Lisp files [Contents][Index]
transform.lisp (file)
staple (system)
code-format.lisp
make-xref-link (function)
Next: The staple/page․lisp file, Previous: The staple/code-format․lisp file, Up: Lisp files [Contents][Index]
code-format.lisp (file)
staple (system)
clip.lisp
Next: The staple/project․lisp file, Previous: The staple/clip․lisp file, Up: Lisp files [Contents][Index]
clip.lisp (file)
staple (system)
page.lisp
Next: The staple/inference․lisp file, Previous: The staple/page․lisp file, Up: Lisp files [Contents][Index]
page.lisp (file)
staple (system)
project.lisp
Next: The staple/documentation․lisp file, Previous: The staple/project․lisp file, Up: Lisp files [Contents][Index]
project.lisp (file)
staple (system)
inference.lisp
Next: The staple-package-recording/recording․lisp file, Previous: The staple/inference․lisp file, Up: Lisp files [Contents][Index]
inference.lisp (file)
staple (system)
documentation.lisp
Next: The staple-code-parser/package․lisp file, Previous: The staple/documentation․lisp file, Up: Lisp files [Contents][Index]
staple-package-recording (system)
recording.lisp
Next: The staple-code-parser/environment․lisp file, Previous: The staple-package-recording/recording․lisp file, Up: Lisp files [Contents][Index]
staple-code-parser (system)
parser/package.lisp
Next: The staple-code-parser/walker․lisp file, Previous: The staple-code-parser/package․lisp file, Up: Lisp files [Contents][Index]
package.lisp (file)
staple-code-parser (system)
parser/environment.lisp
Next: The staple-code-parser/special-forms․lisp file, Previous: The staple-code-parser/environment․lisp file, Up: Lisp files [Contents][Index]
environment.lisp (file)
staple-code-parser (system)
parser/walker.lisp
client (class)
Next: The staple-code-parser/standard-forms․lisp file, Previous: The staple-code-parser/walker․lisp file, Up: Lisp files [Contents][Index]
walker.lisp (file)
staple-code-parser (system)
parser/special-forms.lisp
Next: The staple-code-parser/to-definitions․lisp file, Previous: The staple-code-parser/special-forms․lisp file, Up: Lisp files [Contents][Index]
special-forms.lisp (file)
staple-code-parser (system)
parser/standard-forms.lisp
perform-and-record-macro-expansion (function)
Next: The staple-code-parser/documentation․lisp file, Previous: The staple-code-parser/standard-forms․lisp file, Up: Lisp files [Contents][Index]
standard-forms.lisp (file)
staple-code-parser (system)
parser/to-definitions.lisp
Previous: The staple-code-parser/to-definitions․lisp file, Up: Lisp files [Contents][Index]
to-definitions.lisp (file)
staple-code-parser (system)
parser/documentation.lisp
Next: Definitions, Previous: Files, Up: Top [Contents][Index]
Packages are listed by definition order.
| • The staple package | ||
| • The staple-package-recording package | ||
| • The staple-code-parser package |
Next: The staple-package-recording package, Previous: Packages, Up: Packages [Contents][Index]
package.lisp (file)
org.shirakumo.staple
Next: The staple-code-parser package, Previous: The staple package, Up: Packages [Contents][Index]
recording.lisp (file)
org.shirakumo.staple.recording
common-lisp
Previous: The staple-package-recording package, Up: Packages [Contents][Index]
package.lisp (file)
org.shirakumo.staple.code-parser
Definitions are sorted by export status, category, package, and then by lexicographic order.
| • Exported definitions | ||
| • Internal definitions |
Next: Internal definitions, Previous: Definitions, Up: Definitions [Contents][Index]
| • Exported special variables | ||
| • Exported macros | ||
| • Exported functions | ||
| • Exported generic functions | ||
| • Exported conditions | ||
| • Exported classes | ||
| • Exported types |
Next: Exported macros, Previous: Exported definitions, Up: Exported definitions [Contents][Index]
Pathname to the default Clip template used for simple pages.
See SIMPLE-PAGE
inference.lisp (file)
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.
inference.lisp (file)
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.
inference.lisp (file)
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
project.lisp (file)
Variable bound to the current page during generation.
See PAGE
See GENERATE
Next: Exported functions, Previous: Exported special variables, Up: Exported definitions [Contents][Index]
Shorthand to define a find-definitions method and destructure the arguments of the parse result.
See FIND-DEFINITIONS
to-definitions.lisp (file)
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
transform.lisp (file)
Shorthand to define a sub-results method and destructure the arguments of the parse result.
See SUB-RESULTS
to-definitions.lisp (file)
Shorthand to define a WALK-FORM method.
Adds local functions for WALK and WALK-IMPLICIT-PROGN that
automatically pass the environment along so you don’t need to repeat
it.
See WALK-FORM
walker.lisp (file)
Shorthand to define simple walker forms.
The FORM should be a destructuring description of the kind of form to
walk. The return value of the BODY should be the list of additional
arguments for the parse result. The type and source of the parse
result are automatically added for you.
If you need control over the type or source, look at
DEFINE-WALK-COMPOUND-FORM instead.
See DEFINE-WALK-COMPOUND-FORM
walker.lisp (file)
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
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
toolkit.lisp (file)
Next: Exported generic functions, Previous: Exported macros, Up: Exported definitions [Contents][Index]
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
toolkit.lisp (file)
Augments the given environment with the new values for the given names.
Returns the modified environment.
See LOOKUP
See ENVIRONMENT
environment.lisp (file)
Returns a new environment with the changed values in place.
The old environment is a parent to the new one.
See AUGMENT-ENVIRONMENT!
See ENVIRONMENT
environment.lisp (file)
Turns the given thing into a CL:PACKAGE.
If the thing cannot be coerced, an error is signalled.
toolkit.lisp (file)
Turns the given thing into a DEFINITIONS:PACKAGE.
If the thing cannot be coerced, an error is signalled.
toolkit.lisp (file)
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
toolkit.lisp (file)
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
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
toolkit.lisp (file)
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
project.lisp (file)
Loads the given ASDF:SYSTEM quietly.
This muffles warnings and suppresses *standard-output*.
See ASDF:LOAD-SYSTEM
toolkit.lisp (file)
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
code-format.lisp (file)
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
code-format.lisp (file)
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
code-format.lisp (file)
Marks up the code snippets ignoring parts that fail during markup.
See MARKUP-CODE-SNIPPETS
code-format.lisp (file)
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
toolkit.lisp (file)
Turn the parse-result into a list of definitions and source locations.
For instance:
((:CALL (0 . 10) (:VARIABLE (1 . 5) NULL) (:LITERAL (6 . 9) NIL)))
=> ((#<DEFINITIONS:FUNCTION NULL> (1 . 5)))
This uses FIND-DEFINITIONS to find suitable definitions for a parse
result, as well as SUB-RESULTS to traverse the parse result tree.
See FIND-DEFINITIONS
See SUB-RESULTS
to-definitions.lisp (file)
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
transform.lisp (file)
(setf pathname-type->type) (function)
transform.lisp (file)
pathname-type->type (function)
Returns the list sorted such that the most important, or preferred definitions, come first.
See DEFINITION-IMPORTANCE
toolkit.lisp (file)
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.
toolkit.lisp (file)
Reads the given file to a string and returns it.
toolkit.lisp (file)
Removes the cross-reference resolver of the given name.
See XREF-RESOLVER
Calls each cross-reference resolver with the definition until one returns a valid reference.
See XREF-RESOLVER
See DEFINE-XREF-RESOLVER
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
toolkit.lisp (file)
Turns each def into a list of source and def.
to-definitions.lisp (file)
Performs percent, or url-encoding of the string.
toolkit.lisp (file)
Walk the set of LET bindings in the environment.
Returns a list of cons cells where the CAR is the variable definition
of the binding and the cdr is the parse result of the value.
See WALK
walker.lisp (file)
Same as WALK-IMPLICIT-PROGN, but filters out declarations from the cst.
See WALK-IMPLICIT-PROGN
walker.lisp (file)
Walks the CST as a list of forms and returns the list of parse-results for each form.
See WALK
walker.lisp (file)
Walk a lambda-like structure.
Parses the lambda-list and body forms appropriately and returns a
parse-result for a lambda. The given parser is used to process the
lambda-list.
See WALK-IMPLICIT-PROGN
walker.lisp (file)
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
xref.lisp (file)
(setf xref-resolver) (function)
xref.lisp (file)
xref-resolver (function)
Next: Exported conditions, Previous: Exported functions, Up: Exported definitions [Contents][Index]
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
transform.lisp (file)
inference.lisp (file)
Returns a string representing a unique ID for the given definition.
This is useful for creating links and anchors for definitions in a document.
toolkit.lisp (file)
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
toolkit.lisp (file)
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
toolkit.lisp (file)
This function should return T if the definition should be included in the page’s definitions index.
See DEFINITIONS-INDEX-PAGE
page.lisp (file)
inference.lisp (file)
inference.lisp (file)
inference.lisp (file)
inference.lisp (file)
inference.lisp (file)
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
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
(setf document) (generic function)
automatically generated reader method
inference.lisp (file)
document (generic function)
automatically generated writer method
inference.lisp (file)
automatically generated reader method
inference.lisp (file)
automatically generated writer method
inference.lisp (file)
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
inference.lisp (file)
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
project.lisp (file)
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
inference.lisp (file)
Returns any matching definitions for the given parse result.
All parse results have the structure of (TYPE SOURCE . ARGS).
Thus you can simply destructure it and pass the arguments to this
function to retrieve its definitions.
See DEFINE-DEFINITION-RESOLVER
to-definitions.lisp (file)
to-definitions.lisp (file)
to-definitions.lisp (file)
to-definitions.lisp (file)
to-definitions.lisp (file)
to-definitions.lisp (file)
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
project.lisp (file)
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
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
page.lisp (file)
project.lisp (file)
project.lisp (file)
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
(setf images) (generic function)
inference.lisp (file)
automatically generated reader method
inference.lisp (file)
images (generic function)
automatically generated writer method
inference.lisp (file)
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
project.lisp (file)
inference.lisp (file)
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
(setf input) (generic function)
automatically generated reader method
page.lisp (file)
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
(setf language) (generic function)
automatically generated reader method
page.lisp (file)
Looks up the name in the namespace of the environment.
This will traverse the environment chain upwards until no parent can
be found anymore in case the current environment’s namespace does not
contain the value.
When used as a setf place the value is always stored in the given
environment’s namespace.
See NAMESPACE
See ENVIRONMENT
(setf lookup) (generic function)
environment.lisp (file)
lookup (generic function)
environment.lisp (file)
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
(setf output) (generic function)
automatically generated reader method
project.lisp (file)
automatically generated reader method
page.lisp (file)
output (generic function)
automatically generated writer method
project.lisp (file)
automatically generated writer method
page.lisp (file)
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
inference.lisp (file)
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
recording.lisp (file)
recording.lisp (file)
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
(setf packages) (generic function)
automatically generated reader method
page.lisp (file)
recording.lisp (file)
recording.lisp (file)
packages (generic function)
automatically generated writer method
page.lisp (file)
recording.lisp (file)
page.lisp (file)
recording.lisp (file)
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
inference.lisp (file)
Returns the list of pages that the project generates.
See PAGE
See PROJECT
project.lisp (file)
(setf pages) (generic function)
automatically generated reader method
pages (generic function)
automatically generated writer method
project.lisp (file)
Parses the input and returns a list of parse results, each for one toplevel.
First uses READ-TOPLEVEL to read all toplevel forms, then uses WALK
for each of the read CSTs to turn them into parse results.
See READ-TOPLEVEL
See WALK
walker.lisp (file)
Returns whether the symbol being read is an internal or external symbol.
See PLACEHOLDER
automatically generated reader method
walker.lisp (file)
Returns the symbol-name of the symbol this is a placeholder for.
See PLACEHOLDER
automatically generated reader method
walker.lisp (file)
Returns the symbol-package name of the symbol this is a placeholder for.
See PLACEHOLDER
automatically generated reader method
walker.lisp (file)
Accessor to the page’s project.
See PAGE
(setf project) (generic function)
automatically generated reader method
page.lisp (file)
Reads the toplevel of an input.
The INPUT may be a string, pathname, or a stream (by default). Returns a list of CSTs representing all toplevel forms that were read.
walker.lisp (file)
walker.lisp (file)
walker.lisp (file)
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
toolkit.lisp (file)
project.lisp (file)
project.lisp (file)
page.lisp (file)
page.lisp (file)
page.lisp (file)
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
Returns all parse results that are sub-results of this parse result.
All parse results have the structure of (TYPE SOURCE . ARGS).
Thus you can simply destructure it and pass the arguments to this
function to retrieve its definitions.
See DEFINE-SUB-RESULTS
to-definitions.lisp (file)
to-definitions.lisp (file)
to-definitions.lisp (file)
to-definitions.lisp (file)
to-definitions.lisp (file)
to-definitions.lisp (file)
to-definitions.lisp (file)
to-definitions.lisp (file)
to-definitions.lisp (file)
to-definitions.lisp (file)
to-definitions.lisp (file)
to-definitions.lisp (file)
to-definitions.lisp (file)
to-definitions.lisp (file)
to-definitions.lisp (file)
to-definitions.lisp (file)
to-definitions.lisp (file)
to-definitions.lisp (file)
to-definitions.lisp (file)
to-definitions.lisp (file)
to-definitions.lisp (file)
to-definitions.lisp (file)
to-definitions.lisp (file)
to-definitions.lisp (file)
to-definitions.lisp (file)
to-definitions.lisp (file)
to-definitions.lisp (file)
to-definitions.lisp (file)
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
inference.lisp (file)
Accessor to the system the object is associated with.
See SYSTEM-PAGE
See NO-KNOWN-OUTPUT-DIRECTORY
(setf system) (generic function)
inference.lisp (file)
automatically generated reader method
page.lisp (file)
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
inference.lisp (file)
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
page.lisp (file)
append (short method combination)
Options: :most-specific-first
inference.lisp (file)
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
(setf title) (generic function)
automatically generated reader method
page.lisp (file)
Walks the given CST in the environment.
Should return a parse result structure.
Parse results are lists of the following form:
PARSE-RESULT ::= (TYPE SOURCE . ARGS)
TYPE — The type of the form we’ve walked. Typically this
is a symbol of the form itself, like LAMBDA, or a
keyword if a generic variant is encountered like
for :CALLs and :MACROs.
SOURCE ::= (START . END)
ARGS — Additional arguments for the parse result,
including additional parse-results.
Generally see the overall concrete-syntax-tree system for explanations
on how to use this.
Note that you probably want to define a method on WALK-FORM instead,
as that is called automatically as appropriate for each CST:CONST-CST,
and WALK-ATOM is called for each CST:ATOM-CST.
See ENVIRONMENT
walker.lisp (file)
walker.lisp (file)
walker.lisp (file)
walker.lisp (file)
walker.lisp (file)
walker.lisp (file)
walker.lisp (file)
walker.lisp (file)
walker.lisp (file)
Walks an atom.
If the atom is a symbol, it returns a parse result of a literal for keywords and booleans, or a variable for symbols. For everything else it returns a parse result for a literal.
walker.lisp (file)
walker.lisp (file)
Walks a form.
The form is identified by the car of the cons. The entirety of the form as a CST, including the operator, are passed along as well.
standard-forms.lisp (file)
standard-forms.lisp (file)
standard-forms.lisp (file)
standard-forms.lisp (file)
standard-forms.lisp (file)
special-forms.lisp (file)
special-forms.lisp (file)
special-forms.lisp (file)
special-forms.lisp (file)
special-forms.lisp (file)
special-forms.lisp (file)
special-forms.lisp (file)
special-forms.lisp (file)
special-forms.lisp (file)
special-forms.lisp (file)
special-forms.lisp (file)
special-forms.lisp (file)
special-forms.lisp (file)
special-forms.lisp (file)
special-forms.lisp (file)
special-forms.lisp (file)
special-forms.lisp (file)
special-forms.lisp (file)
special-forms.lisp (file)
special-forms.lisp (file)
special-forms.lisp (file)
special-forms.lisp (file)
special-forms.lisp (file)
special-forms.lisp (file)
special-forms.lisp (file)
special-forms.lisp (file)
special-forms.lisp (file)
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
Next: Exported classes, Previous: Exported generic functions, Up: Exported definitions [Contents][Index]
Error signalled when no known output directory is available for a system.
See SYSTEM
See INFER-PROJECT
inference.lisp (file)
error (condition)
system (method)
:system
system (generic function)
Next: Exported types, Previous: Exported conditions, Up: Exported definitions [Contents][Index]
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
page.lisp (file)
input-page (class)
generate (method)
Superclass for pages that include a definitions index.
See PACKAGES
See FORMAT-DOCUMENTATION
See RESOLVE-SOURCE-LINK
See DEFINITION-WANTED-P
See DEFINITIONS
page.lisp (file)
templated-page (class)
system-page (class)
packages (generic function)
(setf packages) (generic function)
Container for environment information used during walking.
See PARENT
See NAMESPACES
See LOOKUP
See AUGMENT-ENVIRONMENT!
See AUGMENTED-ENVIRONMENT
environment.lisp (file)
standard-object (class)
:parent
parent (generic function)
(make-hash-table :test (quote eq))
namespaces (generic function)
Superclass for pages that are generated using some kind of input.
See PAGE
See INPUT
page.lisp (file)
page (class)
:input
input (generic function)
(setf input) (generic function)
| Initarg | Value |
|---|---|
| :input | nil |
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
page.lisp (file)
standard-object (class)
input-page (class)
:title
title (generic function)
(setf title) (generic function)
:language
:en
language (generic function)
(setf language) (generic function)
:output
output (generic function)
(setf output) (generic function)
:project
project (generic function)
(setf project) (generic function)
| Initarg | Value |
|---|---|
| :output | nil |
| :title | nil |
| :project | (error "project required.") |
This class represents symbols that are not present in the host.
They are emitted in parsed code snippets in place of symbols that
cannot be read properly.
See PLACEHOLDER-NAME
See PLACEHOLDER-PACKAGE
See PLACEHOLDER-INTERN
walker.lisp (file)
standard-object (class)
:name
placeholder-name (generic function)
:package
placeholder-package (generic function)
:intern
placeholder-intern (generic function)
| Initarg | Value |
|---|---|
| :name | (error "name required") |
| :package | nil |
| :intern | nil |
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
project.lisp (file)
standard-object (class)
simple-project (class)
:output
output (generic function)
(setf output) (generic function)
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
inference.lisp (file)
system-page (class)
:document-package
document-package (generic function)
(setf document-package) (generic function)
:document
document (generic function)
(setf document) (generic function)
:images
images (generic function)
(setf images) (generic function)
| Initarg | Value |
|---|---|
| :document | nil |
| :images | nil |
| :document-package | nil |
| :input | staple:*default-template* |
A simple project.
This class simply stores a list of page instances and generates them
when GENERATE is called on the project instance.
See PROJECT
See PAGES
project.lisp (file)
project (class)
:pages
pages (generic function)
(setf pages) (generic function)
| Initarg | Value |
|---|---|
| :pages | nil |
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
page.lisp (file)
input-page (class)
generate (method)
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
page.lisp (file)
definitions-index-page (class)
simple-page (class)
nil
system (generic function)
(setf system) (generic function)
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
page.lisp (file)
input-page (class)
definitions-index-page (class)
Previous: Exported classes, Up: Exported definitions [Contents][Index]
A type representing all possible values to be used with ENSURE-STREAM.
See ENSURE-STREAM
toolkit.lisp (file)
Previous: Exported definitions, Up: Definitions [Contents][Index]
| • Internal special variables | ||
| • Internal macros | ||
| • Internal functions | ||
| • Internal generic functions | ||
| • Internal classes |
Next: Internal macros, Previous: Internal definitions, Up: Internal definitions [Contents][Index]
recording.lisp (file)
project.lisp (file)
transform.lisp (file)
recording.lisp (file)
Next: Internal functions, Previous: Internal special variables, Up: Internal definitions [Contents][Index]
Like CL:CASE, but takes a test function.
TEST must be a function designator or a lambda expression.
See CL:CASE
toolkit.lisp (file)
Executes body for each file in the directory tree.
Evaluates RESULT last and returns its value.
See MAP-DIRECTORY-TREE
toolkit.lisp (file)
Ensures PLACE has a valid value.
This establishes a STORE-VALUE restart around BODY. If the restart is
called, the PLACE is set to the value the restart was called with and
the BODY is executed again.
Typically the BODY will be some kind of check to ensure the validity of the value stored in PLACE. In combination with this macro, that will ensure that the code only ever continues with a valid value in PLACE.
toolkit.lisp (file)
Next: Internal generic functions, Previous: Internal macros, Up: Internal definitions [Contents][Index]
Compacts the given PLUMP:NODE by removing extraneous whitespace.
This will take care not to trim whitespace from <pre> tags, but will replace any duplicate whitespace with a single space anywhere else. Note that this will leave a single space between nodes, as it cannot determine whether the effects of the whitespace in that case are intended or not.
toolkit.lisp (file)
recording.lisp (file)
Makes sure the namespace of the given name exists in the environment.
See ENVIRONMENT
See NAMESPACES
environment.lisp (file)
Attempts to coerce the given designator to a stream object.
The following are handled:
STREAM — The designator is returned verbatim.
STRING/PATHNAME — OPEN is called on the designator using the
given keyword arguments as appropriate.
NULL — A string-output-stream is returned.
T — *STANDARD-OUTPUT* is returned.
See WITH-STREAM
See STREAM-DESIGNATOR
toolkit.lisp (file)
Ensures to return an ASDF:SYSTEM.
If the argument is not already an ASDF:SYSTEM, it is passed to
ASDF:FIND-SYSTEM, and errors if no system can be found.
See ASDF:SYSTEM
See ASDF:FIND-SYSTEM
toolkit.lisp (file)
toolkit.lisp (file)
toolkit.lisp (file)
project.lisp (file)
code-format.lisp (file)
Calls the given function for all files in the directory tree.
If MAX-DEPTH is given, it denotes the maximum number of directories into which it recurses. Specifically, if MAX-DEPTH is 0, only the files in the given directory are mapped to the function. Otherwise each directory is visited recursively with MAX-DEPTH reduced by one.
toolkit.lisp (file)
toolkit.lisp (file)
Accesses the namespace of the given name from the environment.
See NAMESPACES
See ENVIRONMENT
See LOOKUP
environment.lisp (file)
Parses a lisp symbol token, meaning it will read from string by properly interpreting backslashes and vertical bar escapes.
Parses a symbol from the given string identifier.
Explicit packages, keywords, and package-less symbols are handled.
Returns two values, the symbol’s name and its package as strings. If the symbol is a gensym, the returned package name is :GENSYM, rather than an actual package name string.
standard-forms.lisp (file)
Returns T if PREFIX is a whole prefix of STRING.
toolkit.lisp (file)
Reads a value from *query-io*.
To be used with interactive restarts.
toolkit.lisp (file)
Continues reading from the stream until a valid lisp source form is encountered.
This skips both whitespace and comments.
toolkit.lisp (file)
Splits the given string by the given splitting character.
Returns the list of non-empty substrings. The split strings are not shared with the original string.
toolkit.lisp (file)
toolkit.lisp (file)
toolkit.lisp (file)
Attempts to turn the given string into one more suitable as a title.
toolkit.lisp (file)
toolkit.lisp (file)
Next: Internal classes, Previous: Internal functions, Up: Internal definitions [Contents][Index]
Returns the hash-table of namespaces in the environment.
See ENVIRONMENT
See NAMESPACE
automatically generated reader method
environment.lisp (file)
Returns the parent of the environment, if any.
See ENVIRONMENT
automatically generated reader method
environment.lisp (file)
Returns a canonical keyword for the name of the ASDF:SYSTEM.
toolkit.lisp (file)
toolkit.lisp (file)
Previous: Internal generic functions, Up: Internal definitions [Contents][Index]
Our subclass of the eclector cst-client.
Uses the host lisp’s EVAL.
See ECLECTOR.CONCRETE-SYNTAX-TREE::CST-CLIENT
walker.lisp (file)
cst-client (class)
Previous: Definitions, Up: Top [Contents][Index]
| • Concept index | ||
| • Function index | ||
| • Variable index | ||
| • Data type index |
Next: Function index, Previous: Indexes, Up: Indexes [Contents][Index]
| Jump to: | F L S |
|---|
| Jump to: | F L S |
|---|
Next: Variable index, Previous: Concept index, Up: Indexes [Contents][Index]
| Jump to: | (
A C D E F G I L M N O P R S T U W X |
|---|
| Jump to: | (
A C D E F G I L M N O P R S T U W X |
|---|
Next: Data type index, Previous: Function index, Up: Indexes [Contents][Index]
| Jump to: | *
D I L N O P S T |
|---|
| Jump to: | *
D I L N O P S T |
|---|
Previous: Variable index, Up: Indexes [Contents][Index]
| Jump to: | C D E I N P S T |
|---|
| Jump to: | C D E I N P S T |
|---|