is a variable defined in `
Its value is
Association list to control publishing behavior.
Each element of the alist is a publishing 'project.' The CAR of
each element is a string, uniquely identifying the project. The
CDR of each element is in one of the following forms:
1. A well-formed property list with an even number of elements,
alternating keys and values, specifying parameters for the
(:property value :property value ... )
2. A meta-project definition, specifying of a list of
(:components ("project-1" "project-2" ...))
When the CDR of an element of org-publish-project-alist is in
this second form, the elements of the list after `:components'
are taken to be components of the project, which group together
files requiring different publishing options. When you publish
such a project with M-x org-publish, the components all publish.
When a property is given a value in `org-publish-project-alist',
its setting overrides the value of the corresponding user
variable (if any) during publishing. However, options set within
a file override everything.
Most properties are optional, but some should always be set:
Directory containing publishing source files.
Extension (without the dot!) of source files. This can be
a regular expression. If not given, "org" will be used as
Directory (possibly remote) where output files will be
The `:exclude' property may be used to prevent certain files from
being published. Its value may be a string or regexp matching
file names you don't want to be published.
The `:include' property may be used to include extra files. Its
value may be a list of filenames to include. The filenames are
considered relative to the base directory.
When both `:include' and `:exclude' properties are given values,
the exclusion step happens first.
One special property controls which back-end function to use for
publishing files in the project. This can be used to extend the
set of file types publishable by `org-publish', as well as the
set of output formats.
Function to publish file. Each back-end may define its
own (i.e. `org-latex-publish-to-pdf',
`org-html-publish-to-html'). May be a list of functions, in
which case each function in the list is invoked in turn.
Another property allows you to insert code that prepares
a project for publishing. For example, you could call GNU Make
on a certain makefile, to ensure published files are built up to
Function to be called before publishing this project. This
may also be a list of functions.
Function to be called after publishing this project. This
may also be a list of functions.
Some properties control details of the Org publishing process,
and are equivalent to the corresponding user variables listed in
the right column. Back-end specific properties may also be
included. See the back-end documentation for more information.
The following properties may be used to control publishing of
a site-map of files or summary page for a given project.
Whether to publish a site-map during
`org-publish-current-project' or `org-publish-all'.
Filename for output of sitemap. Defaults to "sitemap.org".
Title of site-map page. Defaults to name of file.
Plugin function to use for generation of site-map. Defaults
to `org-publish-org-sitemap', which generates a plain list of
links to all files in the project.
Can be `list' (site-map is just an itemized list of the
titles of the files involved) or `tree' (the directory
structure of the source files is reflected in the site-map).
Defaults to `tree'.
Remove extension from site-map's file-names. Useful to have
cool URIs (see http://www.w3.org/Provider/Style/URI).
Defaults to nil.
If you create a site-map file, adjust the sorting like this:
Where folders should appear in the site-map. Set this to
`first' (default) or `last' to display folders first or last,
respectively. Any other value will mix files and folders.
The site map is normally sorted alphabetically. You can
change this behavior setting this to `anti-chronologically',
`chronologically', or nil.
Should sorting be case-sensitive? Default nil.
The following property control the creation of a concept index.
Create a concept index. The file containing the index has to
be called "theindex.org". If it doesn't exist in the
project, it will be generated. Contents of the index are
stored in the file "theindex.inc", which can be included in
Other properties affecting publication.
Set this to t to publish only the body of the documents.
You can customize this variable.