@c -*- coding: utf-8; mode: texinfo; -*-
@node Documentation work
@chapter Documentation work

There are currently 11 manuals for LilyPond, not counting the
translations.  Each of them is available in split HTML (many small
files), big HTML (a single file), PDF, and Info format.  The
documentation is written in a markup language called @dfn{Texinfo}
-- this allows us to generate different output formats from a
single set of source files.

To allow multiple authors work simultaneously, we also use git (as
previously discussed, @pxref{Working with source code}) for the
documentation.


@node Introduction to documentation work
@section Introduction to documentation work

Our documentation tries to adhere to our documentation policy
(@pxref{Documentation policy}).  This policy contains a few items
which may seem odd.  One policy in particular is often questioned
by potential contributors: we do not repeat material in the
Notation Reference, and instead provide links to the
@qq{definitive} presentation of that information.  Some people
point out, with good reason, that this makes the documentation
harder to read: if we repeated certain information in relevant
places, readers would be less likely to miss that information.

That reasoning is sound, but we have two counter-arguments.
First, the Notation Reference -- one of @emph{five} manuals for
users to read -- is already over 900 pages long.  If we repeated
material, we would easily need a few hundred pages more!  Second,
and much more importantly, LilyPond is an evolving project.  New
features are added, bugs are fixed, and bugs are discovered and
documented.  If features are discussed in multiple places, the
documentation team must find every instance.  Since the manual is
so large, it is impossible for one person to have the location of
every piece of information memorized, so any attempt to update the
documentation will invariably omit a few places.  This second
concern is not at all theoretical; the documentation used to be
plagued with inconsistent information.

If the documentation were targeted for a specific version -- say,
LilyPond 2.24.1 -- and we had unlimited resources to spend on
documentation, then we could avoid this second problem.  However,
since LilyPond evolves (and that is a very good thing!), and since
we have quite limited resources, this policy remains in place.

A few other policies (such as avoiding the use of tweaks in the
main portion of Notation Reference chapters 1 and@tie{}2) may also
seem counter-intuitive, but they also stem from attempting to find
the most effective use of limited documentation help.

Before undertaking any large documentation work, contributors are
encouraged to contact the @email{lilypond-devel@@gnu.org} mailing
list.

@node version in documentation files
@section @code{\version} in documentation files

Every documentation file that includes LilyPond code should begin
with a @code{\version} statement, referencing a version of
LilyPond that is consistent with the syntax of the contained code.
Since the @code{\version} statement is not valid Texinfo input it
must be put into a comment like this:

@example
@@c \version "2.24.1"
@end example

So, if you are adding LilyPond code not consistent with the
current version header, you should

@enumerate

@item
run @command{convert-ly} on the file using the latest version of
LilyPond (which should, if everybody has done proper maintenance,
not change anything);

@item
add the new code;

@item
modify the version number to match the new code.

@end enumerate

@need 1000
@node Documentation suggestions
@section Documentation suggestions

@subheading Small additions

For small additions to the documentation you might follow these
steps.

@enumerate

@item
Tell us where the addition should be placed.  Please include both
the section number and title (for example, @q{LM 2.13 Printing
lyrics}).

@item
Please write exact changes to the text.

@item
A formal patch to the source code is @emph{not} required; we can
take care of the technical details.

@item
Send the suggestions to the @email{bug-lilypond@@gnu.org} mailing
list as discussed in @rweb{Contact}.

@end enumerate

Here is an example of a perfect documentation report:

@indentedblock
@verbatim
To: bug-lilypond@gnu.org
From: helpful-user@example.net
Subject: doc addition

In LM 2.13 (printing lyrics), above the last line ("More options,
like..."), please add:

----
To add lyrics to a divided part, use blah blah blah.  For example,

\score {
  \notes {blah <<blah>> }
  \lyrics {blah <<blah>> }
  blah blah blah
}
----

In addition, the second sentence of the first paragraph is
confusing.  Please delete that sentence (it begins with "Users
often...") and replace it with this:
----
To align lyrics with something, do this thing.
----

Have a nice day,
Helpful User
@end verbatim
@end indentedblock

@subheading Larger contributions

To replace large sections of the documentation, the guidelines are
stricter.  We cannot remove parts of the current documentation
unless we are certain that the new version is an improvement.

@enumerate

@item
Ask on the @code{lilypond-devel} mailing list if such a rewrite is
necessary; somebody else might already be working on this issue!

@item
Split your work into small portions; this makes it much easier to
compare the new and old documentation.

@item
Please prepare a formal git patch, ideally submitted as a
@dfn{Merge Request} for our repository (@pxref{Lifecycle of a
merge request}).

@end enumerate

@subheading Contributions that contain examples using overrides

We try to avoid overrides, tweaks, customer Scheme functions,
etc., as much as possible in examples shown in the main text of
the manuals, as there would be far too many, equally useful,
candidates.

The correct way is to add your example, with appropriate
explanatory text and categories, to the LilyPond Wiki, the
successor of the LilyPond Snippet Repository (LSR).  Snippets that
have the @q{Included in the official documentation} category can
then be easily added as a @emph{selected snippet} in the
documentation.  It will also appear automatically in the
@q{Snippets} manual.  @xref{Introduction to the LilyPond Wiki}.

Snippets that @emph{don't} have the @q{Included in the official
documentation} category will still be searchable and viewable
within the Wiki, but will be not be included in the Snippets list
or be able to be included as part of the main documentation.

Generally, any new snippets that have the @q{Included in the
official documentation} category are more carefully checked for
syntax and formatting.

@subheading Announcing your snippet

Once you have followed these guidelines, please send a message to
@code{lilypond-devel} with your documentation submissions.

We may edit your suggestion for spelling, grammar, or style, and we may
not place the material exactly where you suggested, but if you give us
some material to work with, we can improve the manual much faster.

Thanks for your interest!


@need 1500
@node Texinfo introduction and usage policy
@section Texinfo introduction and usage policy


@node Texinfo introduction
@subsection Texinfo introduction

The markup language we use for writing LilyPond documentation is
called Texinfo; you can see its manual here:

@uref{https://www.gnu.org/software/texinfo/manual/texinfo/}

@noindent
However, you don't need to read those documents.  The most
important thing to notice is that text is text.  If you see a
mistake in the text, you can fix it.  If you want to change the
order of something, you can cut and paste that stuff into a new
location.

@warning{As a rule of thumb, follow the examples in the existing
documentation.  You can learn most of what you need to know from
this; if you want to do anything fancy, discuss it on
@code{lilypond-devel} first.}


@node Documentation files
@subsection Documentation files

All manuals live in subdirectories of
@file{Documentation/@var{XX}}, where @samp{@var{XX}} is a
two-letter language code like @samp{en} for English.  All
non-English documents are translations of the English ones.

Here is a table of the most important user manuals together with
the name of their master source files (the extension @file{.tely}
stands for Texinfo + LilyPond code).

@need 1500
@indentedblock
@multitable {Notation Reference (NR)} {@file{music-glossary.tely}}
@item Learning Manual (LM) @tab @file{learning.tely}
@item Notation Reference (NR) @tab @file{notation.tely}
@item Music Glossary (MG) @tab @file{music-glossary.tely}
@item Application Usage (AU) @tab @file{usage.tely}
@item Extending Guide (EG) @tab @file{extending.tely}
@end multitable
@end indentedblock

Each chapter is put into a separate file, ending in @file{.itely}
for files containing LilyPond code, and @file{.itexi} for files
without LilyPond code (the @q{i} in the file name extension stands
for @q{included}), located in a subdirectory associated with the
manual (@file{learning/} for @file{learning.tely}, and so on);
list the subdirectory of each manual to determine the file name of
the specific chapter you wish to modify.

Developer manuals live in @file{Documentation/} too.  Currently
there is only one: the Contributor's Guide
(@file{contributor.texi}) you are reading right now.

Many snippet files are part of the Notation Reference, and the
Snippet List (SL), which holds all snippets, lives in
@file{Documentation/} just like the manuals; its master file is
called @file{snippets.tely}.  For information about how to modify
the snippet files and SL, @pxref{LilyPond Wiki work}.


@node Sectioning commands
@subsection Sectioning commands

The Notation Reference uses section headings at four, occasionally
five, levels.

@indentedblock
@multitable {@b{level}} {@code{@@unnumberedsubsubsec}}
@headitem level @tab section command
@item 1 @tab @code{@@chapter}
@item 2 @tab @code{@@section}
@item 3 @tab @code{@@subsection}
@item 4 @tab @code{@@unnumberedsubsubsec}
@item 5 @tab @code{@@subsubsubheading}
@end multitable
@end indentedblock

The first three levels are numbered in HTML, the last two are not.
A numbered section corresponds to a single HTML page in the split
HTML documents.

The first four levels always have accompanying @code{@@node}
commands so they can be referenced; they are also included in the
table of contents in HTML.

Most of the manual is written at level@tie{}4 under headings
created with

@example
@@node Foo
@@unnumberedsubsubsec Foo
@end example

Level@tie{}3 subsections are created with

@example
@@node Foo
@@subsection Foo
@end example

Level@tie{}4 headings must be preceded by level@tie{}3 headings,
and so on for level@tie{}3 and level@tie{}2.  If this is not what
is wanted, please use:

@example
@@subsubsubheading Foo
@end example

Leave two blank lines above a @code{@@node}; this makes it easier
to find sections in Texinfo code.

Do not use any @code{@@}-commands within a @code{@@node}.  They
may be used for any @code{@@sub...} sections or headings, however.

@example
not:
@@node @@code@{Foo@} bar
@@subsection @@code@{Foo@} bar

but instead:
@@node Foo bar
@@subsection @@code@{Foo@} bar
@end example

Similarly, do not use punctuation in node names.  If the heading
text uses punctuation (in particular, colons and commas) simply
leave this out.

@example
@@node We all love Bach Mozart and Gregorian chant
@@subsection We all love Bach, Mozart, and Gregorian chant
@end example

As can be seen in the previous examples, we use
@dfn{sentence-style} capitalization (@emph{not} title case), which
means that a heading starts with an uppercase letter, and you
should only capitalize words in the remaining part of the heading
if you would do so in an English sentence.

Backslashes must not be used in node names either.

@example
@@node set and unset
@@subsection @@code@{\set@} and @@code@{\unset@}
@end example

With the exception of @code{@@}-commands, @code{\}-commands and
punctuation, the section name should match the node name exactly.
If it happens that the heading starts with a command name that in
turn starts with a lowercase letter, do not capitalize the command
name in the node name.

Sectioning commands (@code{@@node} and @code{@@section}) must not
appear inside an @code{@@ignore} @dots{} @code{@@end ignore}
block.  Separate those commands with a space, i.e.,
@samp{@@n@tie{}ode}.


@node Menus
@subsection Menus

A Texinfo @dfn{menu} is a @code{@@menu} @dots{} @code{@@end menu}
block that holds node names of all subsections of a section.  By
default, such blocks are auto-generated while creating Info and
HTML output; in PDF output, they are not used.  This means that it
is not necessary to create menus normally.

The auto-generated menus simply use node names (and display the
corresponding section names).  If you want to add some description
to one or more menu entries, however, you have to create the
@code{@@menu} block manually, to be put at the end of the current
node, right before the first subsection node.

Assuming that the current section contains subsection node names
@q{foo}, @q{bar}, and @q{baz}, the syntax is as follows.

@example
@@menu
* foo::    A very long description of an extremely
           important topic.
* bar::
* baz::    All you want to know about @@code@{baz@}.
@@end menu
@end example

As can be seen, the description of a menu entry might contain
Texinfo commands, and it can be broken across multiple lines (in
Info mode, the formatting of the @code{@@menu} block is taken
directly).

In the LilyPond documentation, most top-level menus contain
descriptions.


@node LilyPond formatting
@subsection LilyPond formatting

Here are some guidelines how to format LilyPond code in
@code{@@lilypond} @dots{} @code{@@end lilypond} blocks.

@itemize

@item
Most LilyPond examples throughout the documentation can be produced
with:

@example
@@lilypond[verbatim,quote]
@end example

If you need @code{\book@{@}} in your example then you must also
include the @code{papersize=@var{X}} variable, where
@code{@var{X}} is a paper size as defined in file
@file{scm/@/paper.scm}.  This is to avoid the default @code{a4}
paper size being used and leaving too much unnecessary whitespace
and potentially awkward page breaks in the PDFs.

The preferred @code{papersize} values are @code{a5}, @code{a6}, or
@code{a8landscape}.

@code{a8landscape} works best for a single measure with a single
title and/or a single tagline:

@example
@@lilypond[papersize=a8landscape,verbatim]
\book @{
  \header @{
    title = "A scale in LilyPond"
  @}
  \relative @{
    c d e f
  @}
@}
@@end lilypond
@end example

@noindent
and can also be used to easily show features that require page breaks
(i.e., page numbers) without taking large amounts of space within the
documentation.  Do not use the @code{quote} option with this paper size.

@code{a5} or @code{a6} paper sizes are best used for examples that
have more than two measures of music or require multiple staves
(i.e., to illustrate cross-staff features, right-hand and
left-hand parts, etc.@:) and where @code{\book@{@}} constructions
are required or where @code{a8landscape} produces an example that
is too cramped.  Depending on the example the @code{quote} option
may need to be omitted.

In rare cases, other options may be used (or omitted), but ask first.

@item
For consistency with the existing documentation source code,
please avoid using extra spacing either after or within the
@code{@@lilypond} parameters.

@example
not:          @@lilypond [verbatim, quote, fragment]
but instead:  @@lilypond[verbatim,quote,fragment]
@end example

@item
Inspirational headwords are produced with:

@example
@@lilypondfile[quote,ragged-right,line-width=16\cm,staffsize=16]
@{@var{topic}-headword.ly@}
@end example

@item
LilyPond Wiki snippets are linked with:

@example
@@lilypondfile[verbatim,quote,ragged-right,texidoc,doctitle]
@{@var{name}.ly@}
@end example

@item
Use two spaces for indentation in LilyPond examples (no tabs).

@item
Try to avoid using @code{#'} or @code{#`} when describing context
or layout properties outside of an @code{@@example} or
@code{@@lilypond}, unless the description explicitly requires it.

Example: @qq{@dots{}setting the @code{transparent} property leaves
the object where it is, but makes it invisible.}

@item
If possible, only write one bar per line.

@item
If you only have one bar per line, you might omit bar checks.  If
you must put more than one bar per line (not recommended), then do
include bar checks.

@item
@code{\override} tweaks should, if possible, also occur on their
own line.

@example
not:          \override TextScript.padding = #3 c1^"hi"
but instead:  \override TextScript.padding = #3
              c1^"hi"
@end example

@item
Avoid long stretches of input code.  Nobody is going to read
them in print.  Create small examples.  However, this does not mean
it has to be minimal.

@item
Specify durations for at least the first note of every bar.

@item
If possible, end with a complete bar.

@item
Comments should go on their own line, and be placed before
the line(s) to which they refer.

@item
For clarity, use @samp{@{} and @samp{@}} even if they are not
technically required.

@example
not:

\context Voice \repeat unfold 2 \relative c' @{
  c2 d
@}

but instead:

\context Voice @{
  \repeat unfold 2 @{
    \relative c' @{
      c2 d
    @}
  @}
@}
@end example

@item
Add a space around @samp{@{} and @samp{@}}.

@example
not:          \chordmode@{c e g@}
but instead:  \chordmode @{ c e g @}
@end example

@item
Use @samp{@{} and @samp{@}} for additional @code{\markup} format
commands.

@example
not:          c^\markup \tiny\sharp
but instead:  c^\markup @{ \tiny \sharp @}
@end example

@item
Remove any space around @samp{<} and @samp{>} (except for
situations like @w{@code{<c e g-> >}}, which would cause a syntax
error otherwise).

@example
not:           < c e g > 4
but instead:   <c e g>4
@end example

@item
Beam and slur marks should begin immediately after the first note
(i.e., without a space in between), and end immediately after the
last.  Ties should also be attached without a space before the
tilde sign.

@example
a8\( ais16[ b cis( d] b) cis4~ b' cis,\)
@end example

@item
If you want to work on an example outside of the manual (for
easier/@/faster processing), use this header.

@example
\paper @{
  indent = 0\mm
  line-width = 135.68\mm
@}

\layout @{@}
@end example

@noindent
This is the default line width and indentation value used by
@command{lilypond-book} (which converts the LilyPond code to PDF
or PNG images) for @code{@@lilypond} blocks with the @code{quote}
option and no other overrides.  Without the @code{quote} option,
the line width is 156@dmn{mm}.

@end itemize


@node Text formatting
@subsection Text formatting

@itemize
@item
Lines should be less than 72 characters long.  (We personally
recommend writing with 66-char lines, but do not bother modifying
existing material).  @xref{Syntax survey} for recommendations on
how to use fixed-width fonts.

The main reason for using short lines is that it makes it easy
later on to add a forgotten @code{@@code@{...@}} around a word,
say, without the (aesthetical) need to reformat the text.  Not
reformatting a paragraph makes it much more straightforward to
compare small changes with git repository viewers like
@command{gitk} or @command{TortoiseGit}.

@item
Do not use tabs.

@item
Do not use spaces at the beginning of a line (except in
@code{@@example} or @code{@@verbatim} environments), and do not
use more than a single space between words.  @command{texi2any}
(which processes the Texinfo source files) copies the input lines
verbatim without removing those spaces, and some output formats
(plain text and Info) retain them in the generated output.

@item
Use two spaces after a period.

@item
In examples of syntax, use @code{@@var@{@var{musicexpr}@}} for a
music expression.

@item
Don't use @code{@@rinternals@{@}} in the main text.  If you're
tempted to do so, you're probably getting too close to @qq{talking
through the code}.  If you really want to refer to a context, use
@code{@@code@{@}} in the main text and @code{@@rinternals@{@}} in
the @code{@@morerefs} block.
@end itemize


@need 1500
@node Syntax survey
@subsection Syntax survey


@node Comments
@unnumberedsubsubsec Comments

@itemize
@item
@code{@@c @dots{}} -- single-line comment.

@item
@code{@@ignore} -- multi-line comment:

@example
@@ignore
@dots{}
@@end ignore
@end example
@end itemize


@node Cross-references
@unnumberedsubsubsec Cross-references

Enter the exact @code{@@node} name of the target reference between
the braces (for example, @code{@@ref@{Syntax survey@}}).  While
cross references use the node name as an argument, they are set up
for our documentation to display the corresponding section command
in PDF and HTML output.

@indentedblock
@multitable {@code{@@rinternals}} {General Information webpage}
@headitem command @tab link target
@item @code{@@ref} @tab current manual
@item @code{@@rchanges} @tab Changes file
@item @code{@@rcontrib} @tab Contributor's Guide
@item @code{@@ressay} @tab Engraving Essay
@item @code{@@rextend} @tab Extending Manual
@item @code{@@rglos} @tab Music Glossary
@item @code{@@rinternals} @tab Internals Reference
@item @code{@@rlearning} @tab Learning Manual
@item @code{@@rlsr} @tab a Snippet section
@item @code{@@rprogram} @tab Application Usage
@item @code{@@rnotation} @tab Notation Reference
@item @code{@@rweb} @tab General Information webpage
@end multitable
@end indentedblock

All these commands also have a @code{@@...named} version, which
allows to specify the displayed text for the reference as a second
argument.  This is mainly used in translations, for example
@code{@@rlearningnamed@{I'm hearing voices, J'entends des voix@}}.

If you want to refer to an external manual as a whole instead of a
specific section, use @q{Top} as an argument.  Example:
@code{@@rinternals@{Top@}}.


@node External links
@unnumberedsubsubsec External links

@itemize
@item
@code{@@email@{@dots{}@}} -- create a @code{mailto:} e-mail link.

@item
@code{@@uref@{@var{URL}[, @var{link text}]@}} -- link to an
external URL:

@example
@@uref@{https://www.gnu.org, The GNU project@}
@end example
@end itemize


@node Fixed-width font
@unnumberedsubsubsec Fixed-width font

@itemize
@item
@code{@@code@{@dots{}@}}, @code{@@samp@{@dots{}@}}

Use the @code{@@code@{@dots{}@}} command when referring to
individual, language-specific tokens (keywords, commands,
engravers, Scheme symbols, etc.@:) in the text.  Ideally, a single
@code{@@code@{@dots{}@}} block should fit within one line in the
PDF output.

Use the @code{@@samp@{@dots{}@}} command when you have a short
example of user input (for example, one or two letters), unless it
constitutes an entire @code{@@item} by itself, in which case
@code{@@code@{@dots{}@}} is preferable.  Otherwise, both should
only be used when part of a larger sentence within a paragraph or
@code{@@item}.  Do not use @code{@@code@{@dots{}@}} or
@code{@@samp@{@dots{}@}} inside an @code{@@example} block, and do
not use either as a free-standing paragraph; use @code{@@example}
instead.

A single, unindented line in the PDF has space for about 79
fixed-width characters (76 if indented).  Within an @code{@@item}
there is space for about 75 fixed-width characters.  Each
additional level of @code{@@itemize} or @code{@@enumerate}
shortens the line by about 4 columns.

However, even short blocks of @code{@@code@{@dots{}@}} and
@code{@@samp@{@dots{}@}} can run into the margin if the Texinfo
line-breaking algorithm gets confused.  Additionally, blocks that
are longer than this may in fact print nicely; it all depends
where the line breaks end up.  If you compile the documentation by
yourself, check the PDF output to make sure the line breaks are
satisfactory.

The Texinfo setting @code{@@allowcodebreaks} is set to
@code{false} in the manuals, so lines within
@code{@@code@{@dots{}@}} or @code{@@samp@{@dots{}@}} blocks will
only break at spaces, not at hyphens or underscores.  If the block
contains significant spaces, use @code{@@w@{@@code@{@dots{}@}@}}
or @code{@@w@{@@samp@{@dots{}@}@}} to prevent unexpected line
breaks.

The Texinfo settings @code{txicodequoteundirected} and
@code{txicodequotebacktick} are both set in the manuals, so
backticks (@code{`}) and apostrophes (@code{'}) placed within
blocks of @code{@@code}, @code{@@example}, or @code{@@verbatim}
are not converted to left- and right-angled quotes
(@code{@quoteleft{} @quoteright{}}) as they normally are within
the text, so the apostrophes in
@q{@w{@code{@@w@{@@code@{\relative c''@}@}}}} will display
correctly.  However, these settings do not affect the PDF output
for anything within a @code{@@samp} block (even if it includes a
nested @code{@@code} block), so entering
@q{@code{@@w@{@@samp@{\relative c''@}@}}} wrongly produces
@q{@w{@code{\relative c@quoteright{}@quoteright{}}}} in PDF.
Consequently, if you want to use a @code{@@samp@{@dots{}@}} block
which contains backticks or apostrophes, you should instead use
@q{@code{@@q@{@@code@{@dots{}@}@}}} (or
@q{@code{@@q@{@@w@{@@code@{@dots{}@}@}@}}} if the block also
contains significant spaces).

@item
@code{@@command@{@dots{}@}} -- Use when referring to command-line
commands within the text (e.g., @samp{@@command@{convert-ly@}}).
Do not use inside an @code{@@example} block.

@item
@code{@@example} -- Use for examples of program code.  Do not add
extraneous indentation (i.e., don't start every line with
whitespace).  Use the following layout (notice the use of blank
lines).  Omit the @code{@@noindent} if the text following the
example starts a new paragraph:

@example
@var{@dots{}text leading into the example@dots{}}

@@example
@dots{}
@@end example

@@noindent
@var{continuation of the text@dots{}}
@end example

Individual lines within an @code{@@example} block should not
exceed 74 characters; otherwise they will run into the margin in
the PDF output, and may get clipped.  If an @code{@@example} block
is part of an @code{@@item}, individual lines in the
@code{@@example} block should not exceed 70 columns.  Each
additional level of @code{@@itemize} or @code{@@enumerate}
shortens the line by about 4 columns.

For long command-line examples, if possible, use a trailing
backslash to break up a single line, indenting the next line with
2 spaces.  If this isn't feasible, use @samp{@@smallexample
@dots{} @@end@tie{}smallexample} instead, which uses a smaller
font size.  Use @code{@@example} whenever possible, but if needed,
@code{@@smallexample} can fit up to 90 characters per line before
running into the PDF margin.  Each additional level of
@code{@@itemize} or @code{@@enumerate} shortens a
@code{@@smallexample} line by about 5 columns.

@item
@code{@@file@{@dots{}@}} -- Use when referring to file names, file
name extensions, and directories in the text.  Do not use inside
an @code{@@example} block.

@item
@code{@@option@{@dots{}@}} -- Use when referring to command-line
options in the text (e.g., @samp{@@option@{--format@}}).  Do not
use inside an @code{@@example} block.

@item
@code{@@verbatim} -- Print the block exactly as it appears in the
source file (including whitespace, etc.), without handling any
Texinfo commands.  The characters @samp{@@}, @samp{@{}, and
@samp{@}} don't need to be quoted with a leading @samp{@@}
character.  For program code examples, use @code{@@example}
instead.  @code{@@verbatim} uses the same format as
@code{@@example}.

Individual lines within an @code{@@verbatim} block should not
exceed 74 characters; otherwise they will run into the margin in
the PDF output, and may get clipped.  If an @code{@@verbatim}
block is part of an @code{@@item}, individual lines in the
@code{@@verbatim} block should not exceed 70 columns.  Each
additional level of @code{@@itemize} or @code{@@enumerate}
shortens the line by about 4 columns.
@end itemize


@node Indexing
@unnumberedsubsubsec Indexing

Use the following two commands.

@itemize
@item
@code{@@cindex @dots{}} -- for the general index
@item
@code{@@funindex @dots{}} -- for commands and properties like
@code{\bar} or @code{left-@/margin}
@end itemize

Here are some rules how index entries should look like.

@itemize
@item
Only capitalize the first word of a @code{@@cindex} entry if you
would do so in the middle of an English sentence.  Examples:

@example
@@cindex ancient clef
@@cindex Kievan clef
@end example

@code{@@funindex} entries are written as-is; don't omit the
leading backslash if there is one.

@item
Use singular forms as much as possible.  After a comma, use
whatever looks better.  Examples:

@example
@@cindex clef
@@cindex fingering instruction, for chords
@end example

@item
Permute index entries if it makes sense.  Example:

@example
@@cindex ancient note head
@@cindex note head, ancient
@end example

@item
Try to make entries fit into groups so that the printed index
looks like this:

@example
@dots{}
text, framing
text, horizontal alignment
text, in columns
text, in volta bracket
text, justified
@dots{}
@end example

@item
Don't insert @code{@@funindex@{\foo@}} and @code{@@cindex@{\foo@}}
simultaneously.

@item
If both @code{foo} and @code{\foo} need to be indexed with
@code{@@funindex} you have to use the @code{@@funindexpre} or
@code{@@funindexpost} command: @code{@@funindexpre foo} gets
sorted before @code{@@funindex \foo}, and @code{@@funindexpost
\foo} gets sorted after @code{@@funindex foo}.  Example:

@example
@@funindex [
@@funindexpost \[
@end example

@item
If you mention entities in a @code{@@cindex} entry that would
normally be entered with @code{@@funindex}, use @code{@@code} to
mark them.  Example:

@example
@@cindex @@code@{\context@}, in @@code@{\layout@} block
@end example

@item
To get a literal @samp{@{} or @samp{@}} in an index, write
@code{@@@{} and @code{@@@}}, respectively.

@item
As of November 2022, if an index entry starts with an accented
character, use a Texinfo accent macro instead of the real
character.  For example, an index entry for @q{Äolisch} should be
entered as

@example
@@cindex @@"Aolisch
@end example

@noindent
to circumvent a problem with @command{texindex} (used by Texinfo
to sort and unify index entries in PDF output): this program
currently has no support for locale-specific collation.  In the
above example, the entry is now sorted as @q{Aolisch}.

In case this is not sufficient it is always possible to explicitly
specify a sorting key using the @code{@@sortas} command: Assuming
that entries starting with letter @q{ä} must be sorted after all
entries starting with letter @q{a}, writing

@example
@@cindex @@sortas@{azzzAolisch@} Äolisch
@end example

@noindent
would make this work.  Unfortunately, this trick doesn't create an
initial letter in the printed index for entries starting with
@q{Ä}.

@end itemize


@node Lists
@unnumberedsubsubsec Lists

@itemize
@item
@code{@@enumerate} -- create an ordered list (with numbers).
Always put @samp{@@item} on its own line.  As an exception, if all
the items in the list are short enough to fit on single lines,
placing them on the @samp{@@item} lines is also permissible.
@samp{@@item} and @samp{@@end@tie{}enumerate} should be preceded
by a blank line except for short, compact entries (this is for
Info file generation).

@example
@@enumerate

@@item
A long multi-line item like this one must begin
on a line of its own and all the other items in
the list must do so too.

@@item
Even short ones

@@end enumerate
@end example

@example
@@enumerate

@@item Short item

@@item Short item

@@end enumerate
@end example

@item
@code{@@itemize} -- create an unordered list (with bullets).  Use
the same format as @code{@@enumerate}.  Do not use
@samp{@@itemize@tie{}@@bullet}.
@end itemize


@node Special characters
@unnumberedsubsubsec Special characters

@warning{In Texinfo, the backslash is an ordinary character, and
is entered without escaping (e.g.
@samp{The@tie{}@@code@{@bs{}foo@}@tie{}command}).  However, within
double-quoted Scheme and/or LilyPond strings, backslashes
(including those ending up in Texinfo markup) need to be escaped
by doubling them:
@example
(define (foo x)
  "The @@code@{@bs{}@bs{}foo@} command..."
  ...)
@end example
}

@itemize
@item
@code{--}, @code{---} -- create an en dash (--) or an em dash
(---) in the text.  To print two or three literal hyphens in a
row, wrap one of them in a @code{@@w@{@dots{}@}} (e.g.,
@samp{-@@w@{-@}-}).  Note that the LilyPond manuals almost never
use em dashes in text.

@item
@code{@@@@}, @code{@@@{}, @code{@@@}} -- create an at-sign
(@samp{@@}), a left brace (@samp{@{}), or a right brace
(@samp{@}}).

@item
@code{@@tie@{@}} -- create a @emph{variable-width}, non-breaking
space in the text (use @w{@samp{@@w@{ @}}} for a single
@emph{fixed-width}, non-breaking space).  Variables or numbers
that consist of a single, unquoted character (probably followed by
a punctuation mark) should be tied properly, either to the
previous or to the next word depending on context.  Example:
@samp{@dots{} item@@tie@{@}3 in the previous list @dots{}}
@end itemize


@node Miscellany
@unnumberedsubsubsec Miscellany

@itemize
@item
@code{@@notation@{@dots{}@}} -- refer to pieces of notation,
e.g., @samp{@@notation@{clef@}}.  Also use for specific lyrics
(@samp{the @@notation@{A@tie{}-@tie{}men@} is centered}).  Only
use once per subsection per term.

@item
@code{@@q@{@dots{}@}} -- single quotes.  Used for
@quoteleft{}vague@quoteright{} terms.  This is the preferred
quoting mechanism in the LilyPond manuals.

@item
@code{@@qq@{@dots{}@}} -- double quotes.  Used for actual quotes
(@qq{he said}) or for introducing special input modes.

@item
@code{@@var@{@dots{}@}} -- use for metasyntactic variables (such
as @code{@var{foo}}, @code{@var{bar}}, @code{@var{arg1}}, etc.).
In most cases, when the @code{@@var@{@dots{}@}} command appears in
the text (and not in an @code{@@example} block) it should be
wrapped with an appropriate code-highlighting Texinfo command
(such as @code{@@code}, @code{@@samp}, @code{@@file},
@code{@@command}, etc.).  For example:
@samp{@@code@{@@var@{foo@}@}},
@samp{@@file@{@@var@{myfile.ly@}@}}, @w{@samp{@@samp@{git switch
@@var@{branch@}@}}}, etc.  This improves readability in the PDF
and HTML output.

@item
@code{@@version@{@}} -- return the current LilyPond version
string.  Use @samp{@@w@{@@version@{@}@}} if it's at the end of a
line (to prevent an ugly line break in PDF); use
@samp{@@w@{"@@version@{@}"@}} if you need it in quotes.

@item
@code{@@w@{@dots{}@}} -- do not allow any line breaks.

@item
@code{@@warning@{@dots{}@}} -- produce a @qq{Note:@tie{}} box.
Use for important messages.
@end itemize


@node Other text concerns
@subsection Other text concerns

@itemize
@item
References should occur at the end of a sentence; for more
information see the
@uref{https://www.gnu.org/software/texinfo/manual/texinfo/,Texinfo
manual}.  Ideally this should also be the final sentence of a
paragraph, but this is not required.  Any link in a doc section
must be duplicated in the @code{@@morerefs} section at the bottom.

@item
Introducing examples should be done with

@example
. (i.e., finish the previous sentence/paragraph)
: (i.e., 'in this example:')
, (i.e., 'may add foo with the blah construct,')
@end example

The method @qq{sentence runs directly into the example} is
discouraged.

@item
Write abbreviation and acronyms in uppercase letters, e.g., HTML,
DVI, MIDI.

@item
Colon usage

@enumerate
@item
To introduce lists.

@item
When beginning a quote: @qq{So, he said,...}.

This usage is rarer.  Americans often just use a comma.

@item
When adding a defining example at the end of a sentence.
@end enumerate

@item
Non-ASCII characters should be directly used; this is, don't say
@samp{Ba@@ss@{@}tuba} but @samp{Baßtuba}.  This ensures that all
such characters appear in all output formats.  There are
limitations for PDF output, though, because the used fonts only
support a relatively small number of Unicode
characters.@footnote{This might change in the future since recent
versions of Texinfo support output to @LaTeX{}, which doesn't have
this limitation.}

@end itemize


@need 1500
@node Documentation policy
@section Documentation policy


@node Books
@subsection Books

The five main parts of the documentation are the Learning Manual,
the Notation Reference, the Application Usage, the Music
Glossary, and the Internals Reference.

@itemize

@item
Learning Manual

The LM is written in a tutorial style which introduces the most
important concepts, structure and syntax of the elements of a
LilyPond score in a carefully graded sequence of steps.
Explanations of all musical concepts used in the manual can be
found in the Music Glossary, and readers are assumed to have no
prior knowledge of LilyPond.  The objective is to take readers to
a level where the Notation Reference can be understood and
employed to both adapt the templates in the Appendix to their
needs and to begin to construct their own scores.  Commonly used
tweaks are introduced and explained.  Examples are provided
throughout which, while being focused on the topic being
introduced, are long enough to seem real in order to retain the
readers' interest.  Each example builds on the previous material,
and comments are used liberally.  Every new aspect is thoroughly
explained before it is used.

Users are encouraged to read the complete Learning Manual from
start to finish.

@item
Notation Reference

This is a (hopefully complete) description of LilyPond's input
notation.  Some material from here may be duplicated in the
Learning Manual (for teaching), but consider the NR to be the
@q{definitive} description of each notation element, with the LM
being an @q{extra}.  The goal is @emph{not} to provide a
step-by-step learning environment -- do not avoid using notation
that has not be introduced previously in the NR (for example, use
@code{\break} if appropriate).  The NR is written in formal
technical writing style.

Avoid duplication.  Although users are not expected to read this
manual from start to finish, they should be familiar with the
material in the Learning Manual (particularly @qq{Fundamental
Concepts}), so do not repeat that material in each section of this
book.  Also watch out for common constructs, like @samp{^},
@samp{-}, and @samp{_} for directions -- those are explained in NR
chapter@tie{}5.  In NR chapter@tie{}1, for example, you can use a
reference and write:

@example
Dynamics may be manually placed above or below the staff, see
@@ref@{Direction and placement@}.
@end example

Most tweaks should be added to snippets in the LilyPond Wiki and
not placed directly in the @file{.itely} file.  In some cases,
tweaks may be placed in the main text, but ask about this first.

Finally, you should assume that users know what the notation
means; explaining musical concepts happens in the Music Glossary.

@item
Application Usage

This manual gives information about calling and using the
@command{lilypond} program itself and other tools related to it
(in particular @command{convert-ly} and @command{lilypond-book}),
issues related to differences in the used operating system, some
pointers to external programs, etc.  This manual is written in
formal technical writing style.

Users are not expected to read this manual from start to finish.

@item
Music Glossary

Information about the music notation itself.  Explanations and
translations about notation terms go here.

Users are not expected to read this manual from start to finish.

@item
Internals Reference

This manual is automatically generated from documentation strings
embedded in the source code.  It provides an in-depth reference to
almost all low-level details of LilyPond.

Users are not expected to @emph{read} this manual at all.  It
should rather be used like a dictionary to look up, say, all
properties and sub-properties of a slur.  The writing style is
extremely terse and technical (sometimes too terse, admittedly).

@end itemize


@node Section organization
@subsection Section organization

@itemize

@item
The order of headings inside documentation sections should
be:

@example
documentation text

@@predefined
@@endpredefined

@@snippets

@@morerefs
@@endmorerefs

@@knownissues
@end example

@item
You @emph{must} include a @code{@@morerefs} @dots{}
@code{@@endmorerefs} block.

@itemize @minus{}
@item
The order of items inside the @code{@@morerefs} block is

@example
Music Glossary:
@@rglos@{foo@},
@@rglos@{bar@}.

Learning Manual:
@@rlearning@{baz@},
@@rlearning@{foozle@}.

Notation Reference:
@@rnotation@{faazle@},
@@rnotation@{boo@}.

Application Usage:
@@rprogram@{blah@}.

Essay on automated music engraving:
@@ressay@{yadda@}.

Extending LilyPond:
@@rextend@{frob@}.

Installed Files:
@@file@{path/to/dir/blahz@}.

Snippets:
@@rlsr@{section@}.

Internals Reference:
@@rinternals@{fazzle@},
@@rinternals@{booar@}.
@end example

@item
If there are multiple entries, separate them by commas only and do
not use the word @q{and}.  If there are no references to a
specific manual, omit it.

@item
Always end with a period.

@item
Place each link on a new line as above; this makes it much easier
to add or remove links.  In the output, they appear on a single
line.

@item
Any new concepts or links which require an explanation should
appear as a full sentence(s) in the main text.

@item
Don't insert an empty line between @code{@@morerefs} and the first
entry!  Otherwise there is excessive vertical space in the PDF
output.

@end itemize

@item
Use @code{@@ref@{...@}} instead of the abovementioned reference
commands if the link is within the same manual.

@item
@code{@@predefined} @dots{} @code{@@endpredefined} is for commands
defined in files @file{ly/@/*-init.ly}.

@item
Do not include any real information in second-level sections (for
example, @q{1.1 Pitches}).  A first-level section may have
introductory material, but other than that all material goes into
third-level sections (for example, @q{1.1.1 Writing Pitches}).

@item
The @code{@@knownissues} part should usually not describe any
issues that are in LilyPond's bug tracker.  The goal is rather to
discuss any overall architecture or syntax decisions, which may be
interpreted as bugs.  Normal bugs should not be discussed here,
because we have so many of them that it would be a huge task to
keep @code{@@knownissues} current and accurate all the time.

@end itemize


@node Checking cross-references
@subsection Checking cross-references

Cross-references between different manuals are heavily used in the
documentation, but they do not cause errors during the compilation
-- the documentation generator, @command{texi2any}, only reports
invalid cross-references within the same manual.  However, if you
compile the documentation, a script called
@command{check_texi_refs.py} can help you with checking and fixing
these cross-references.

To make this work properly you have to configure LilyPond for an
in-tree build (@pxref{Running autogen}), followed by calling
@command{make} and @command{make doc}.

Normally, you don't call @command{check_texi_refs.py} by yourself;
instead, two @command{make} targets are provided for this task.
To call them, first change the current directory to the LilyPond
source tree where the documentation was built, then enter the
@code{Documentation} directory and run:

@example
make check-xrefs
make fix-xrefs
@end example

Be careful with the second command since it can change
documentation files without further asking.

In case you have to fix cross-references in generated
documentation like the Internals Reference you must locate the
corresponding source code files by yourself.  Scan the directories
@file{scm/} for Scheme code and @file{lily/} for C++ code.
@xref{Searching}.


@node General writing
@subsection General writing

@itemize

@item
Do not forget to create @code{@@cindex} entries for new sections
of text.  Commands usually need a @code{@@funindex} entry, for
example,

@example
@@cindex pitches, writing in different octaves
@@funindex \relative
@end example

@noindent
Do not add @code{@@code@{...@}} around the @code{@@funindex}
argument; this is handled internally.  While @code{@@cindex}
entries get added to the main index only, @code{@@funindex}
entries are added to both the command index and the main index.
Both index commands should go in front of the actual material
(each on a separate line).

@item
@code{@@cindex} entries should not be capitalized, i.e.,

@example
@@cindex time signature
@end example

@noindent
is preferred instead of @qq{Time signature}.  Only use capital
letters for musical terms which demand them, e.g.,
@qq{D.S. al Fine}.

@item
For Scheme function index entries, only include the final part,
i.e.,

@example
@@funindex modern-voice-cautionary
     and NOT
@@funindex #(set-accidental-style modern-voice-cautionary)
@end example

@item
Use American spelling.  LilyPond's internal property
names use this convention.

@item
Here is a list of preferred terms to be used:

@itemize @minus{}
@item
@emph{Simultaneous}, NOT concurrent.

@item
@emph{Measure}: the unit of music.

@item
@emph{Bar line}: the symbol delimiting a measure, NOT barline.

@item
@emph{Note head}, NOT notehead.

@item
@emph{Chord construct}, NOT just chord (when referring to
@code{<...>}).

@item
@emph{Staff}, NOT stave.

@item
@emph{Staves}, NOT Staffs:
phrases such as

@example
multiple @@internalsref@{Staff@}s
@end example

@noindent
should be rephrased to

@example
multiple @@internalsref@{Staff@} contexts
@end example

@end itemize

@end itemize


@node Technical writing style
@subsection Technical writing style

The topics discussed here refer to the NR.  The LM uses a more
gentle, colloquial style.

@itemize

@item
Do not refer to LilyPond in the text.  The reader knows what the
manual is about.  If you do, capitalization is LilyPond.

@item
If you explicitly refer to @q{lilypond} the program (or any other
command to be executed), write @code{@@command@{lilypond@}}.

@item
Do not explicitly refer to the reader or user.  There is no one
else besides the reader and the writer.

@item
Avoid contractions (don't, won't, etc.).  Spell the words out completely.

@item
Avoid abbreviations, except for commonly used abbreviations of
foreign language terms such as @q{etc.@:} and @q{i.e.@:} (which
should be both followed by a comma if mid sentence, by the way).

@item
Avoid fluff (@qq{Notice that,} @qq{as you can see,}
@qq{Currently,}).

@item
The use of the word @q{illegal} is inappropriate in most cases.
Say @q{invalid} instead.

@end itemize


@need 1500
@node Tips for writing documentation
@section Tips for writing documentation


@node Working on subsections
@subsection Working on subsections

In the NR, we highly recommend focusing on one subsection at a
time.  For each subsection,

@itemize

@item
check the mundane formatting.  Are the headings
(@code{@@predefined}, @code{@@morerefs}, etc.@:) in the right
order?

@item
add any appropriate index entries.

@item
check the links in the @code{@@morerefs} section -- links to the
Music Glossary, the Internals Reference, and other NR sections are
the main concern.  Check for potential additions.

@item
move material that makes sense if processed stand-alone into the
LilyPond Wiki as a snippet, then delete the material from the
@file{.itely} file and replace it with a @code{@@lilypondfile}
command.

@item
check the examples and descriptions.  Do they still work?
@strong{Do not} assume that the existing text is accurate or
complete; some parts of the manual are highly out of date due to
the constant lack of manpower.

@item
is the material in the @code{@@knownissues} block still accurate?

@item
can the examples be improved (for example, made more explanatory),
or is there any missing information?  Feel free to ask specific
questions on the @code{lilypond-user} mailing list; a couple of
people claimed to be interesting in being @qq{consultants} who
would help with such questions.

We favor short text explanations with good examples -- @qq{an
example is worth a thousand words}.  However, producing good, tiny
LilyPond examples can be quite time-consuming; making
easily-understandable examples is much harder than it looks.

@end itemize

@subsubheading Tweaks

In general, any @code{\set} or @code{\override} command should go
in the @qq{selected snippets} section, which means that they
should be added to the LilyPond Wiki and not to the @file{.itely}
file.  For some cases, the command obviously belongs in the
@qq{main text} (i.e., not inside @code{@@predefined} or
@code{@@morerefs} or whatever) -- instrument names are a good
example of this:

@example
\set Staff.instrumentName = "foo"
@end example

On the other side of this,

@example
\override Score.Hairpin.after-line-breaking = ##t
@end example

@noindent
clearly belongs to a snippet in the LilyPond Wiki.

One place where a documentation writer can profitably spend time
writing or upgrading tweaks is creating code to deal with known
issues.  It would be ideal if every significant known issue had a
workaround to avoid the difficulty.

@morerefs
@ref{Adding and editing snippets}.
@endmorerefs


@node Searching
@subsection Searching

If you are working with the git repository, the most useful tool
on the command line to search text is @command{git grep}, which
recursively scans the repository's files for strings using
@dfn{regular expressions} (regex).  This manual cannot give an
introduction into the use of regular expressions; there are plenty
of resources in the internet that may help you.

Files not managed by git in a repository (for example, all files
generated during compilation or building the documentation) cannot
be searched with @command{git grep}, though.  In such cases you
might use the standard @command{grep} tool instead, which has
almost exactly the same syntax.

Another limitation of both @command{grep} and @command{git grep}
is their inability to search a string across multiple
lines,@footnote{There is limited support for multi-line searching
with recent versions of standard @command{grep}.  However, it
cannot display context around the matches for technical reasons.}
which would be extremely helpful in finding arguments of Texinfo
commands.  A solution is to use a variant of grep called
@command{pcregrep} (or its newer version @command{pcre2grep} --
the acronym PCRE stands for Perl Compatible Regular Expressions).
You most likely have to install this program; look for packages
called @q{pcre-tools}, @q{pcre2-tools}, or something similar.

As an example, let's assume that you want to find all occurrences
of @code{@@rweb@{Easier editing@}} within
@file{Documentation/en/}.  After changing to this directory, a
search with

@example
git grep '@@rweb@{Easier\s*editing@}'
@end example

@noindent
might return the following.

@example
usage/external.itely:editors are listed in @@rweb@{Easier editing@}.
usage/external.itely:are listed in @@rweb@{Easier editing@}.
@end example

@noindent
[The string @code{\s*} means to search for whitespace (@code{\s})
zero or more times in succession (@code{*}).]

On the other hand, a search with

@example
pcregrep -r -M '@@rweb@{Easier\s*editing@}' .
@end example

@noindent
shows one more hit.

@example
./learning/installing.itely:For more information, see @@rweb@{Easier
editing@}.
./usage/external.itely:editors are listed in @@rweb@{Easier editing@}.
./usage/external.itely:are listed in @@rweb@{Easier editing@}.
@end example

[Option @option{-r} enables recursive searching of the current
directory (@samp{.}), option @option{-M} activates multi-line
searching.]


@node Scripts to ease documentation work
@section Scripts to ease documentation work

Since the whole LilyPond documentation build process is slow,
intimidatingly complex, and hard to master even for experts, tools
have been developed over time to help authors handle the most
daunting tasks.


@node Building only one section of the documentation
@subsection Building only one section of the documentation

In order to save build time, a script is available to build and
immediately display only one section of the documentation in
English with a default HTML appearance.

Call the script as follows.

@example
scripts/auxiliar/doc-section.sh @var{manual} @var{section}
@end example

@noindent
@code{@var{section}} is the name of the file containing the
section to be built, and @code{@var{manual}} is replaced by the
name of the directory containing the section.  So, for example, to
build section 1.1 of the Notation Reference, use the command:

@example
scripts/auxiliar/doc-section.sh notation pitches
@end example

You can then see the generated document for the section at

@example
build/tempdocs/pitches/out/pitches.html
@end example

To make this actually work it is necessary to first configure and
compile LilyPond.  Furthermore, the script listens to some
environment variables.

@itemize
@item
The location of the top-level directory of LilyPond's git
repository can be set with the @env{LILYPOND_GIT} environment
variable.  If not specified, the script tries to auto-detect its
location.

@item
The location of the compilation directory can be set with the
@env{LILYPOND_BUILD_DIR} environment variable.  If not specified,
the @file{build/} directory in the git repository's top-level
directory is tried.

@item
The location of the script's output directory can be set with the
@env{LILYPOND_TEMPDOCS} environment variable.  If not specified,
it uses the @file{tempdocs/} subdirectory within the compilation
directory.

@item
The used browser to display the final HTML page defaults to
Firefox; this can be changed by setting the standard @env{BROWSER}
environment variable (which you probably have already set in your
environment).
@end itemize

If these variables are set up correctly, you can call the script
from any directory on your computer.  If you configure the build
process as recommended (@pxref{Configuring make}), i.e., building
in the git repository's top-level subdirectory called
@file{build/}, you don't even need to set any of those environment
variables.

This script will not work for building sections of the
Contributor's Guide.  To do that, use:

@example
scripts/auxiliar/cg-section.sh @var{section}
@end example

@noindent
where @code{@var{section}} is the name of the file containing the
section(s) to be built.  For example, to build chapter@tie{}5 of
the Contributor's Guide, use:

@example
scripts/auxiliar/cg-section.sh doc-work
@end example

The @command{cg-section.sh} script uses the same environment
variables and corresponding default values as
@command{doc-section.sh}.


@node Updating documentation with convert-ly
@subsection Updating documentation with @command{convert-ly}

Don't.  This should be done by programmers when they add new
features.  If you notice that it hasn't been done, complain to
@code{lilypond-devel}.


@node Documentation strings in the Internals Reference
@section Documentation strings in the Internals Reference

Material in the Internals Reference is generated automatically
from our source code.  Any documentation work on the IR therefore
requires modifying files in the @file{scm/} or @file{lily/}
directories.  Texinfo formatting should be used in these
documentation strings.

Most documentation writers never touch these, though.  If you want
to work on them, please ask for help.


@need 1500
@node Translating the documentation
@section Translating the documentation


@node Getting started with documentation translation
@subsection Getting started with documentation translation

First, get the sources from the git repository, @pxref{Working
with source code}.


@node Translation requirements
@unnumberedsubsubsec Translation requirements

Working on LilyPond documentation translations requires the following
pieces of software, in order to make use of dedicated helper tools:

@need 1000
@itemize
@item Python 3.8 or higher,
@item GNU make,
@item gettext,
@item git.
@end itemize

It is not required to build LilyPond and the documentation to
translate the documentation.  However, if you have enough time and
motivation and a suitable system, it can be very useful to build
at least the documentation so that you can check the output
yourself and more quickly; if you are interested,
@pxref{Compiling}.

Before undertaking any large translation work, contributors are
encouraged to contact the @code{lilypond-devel} mailing list.

@node Which documentation can be translated
@unnumberedsubsubsec Which documentation can be translated

The makefiles and scripts infrastructure currently supports translation
of the following documentation:

@itemize
@item the website, the Learning Manual, the Notation Reference and
Application Usage

@item the Changes document, the Music Glossary, the Essay
@end itemize

Support for translating the following pieces of documentation is
not yet available.

@itemize
@item automatically generated documentation: markup commands,
predefined music functions;
@item the Internals Reference.
@end itemize


@node Starting translation in a new language
@unnumberedsubsubsec Starting translation in a new language

At top of the source directory, do

@example
./autogen.sh
@end example

@noindent
or (if you want to install your self-compiled LilyPond locally)

@example
./autogen.sh --prefix=$HOME
@end example

@noindent
If you want to compile LilyPond -- which is required to build the
documentation, but is not required to do translation only -- fix
all dependencies and rerun @command{./configure} (with the same
options as for @command{autogen.sh}).

Then @command{cd} into @file{Documentation/} and run

@example
make ISOLANG=@var{MY-LANGUAGE} new-lang
@end example

@noindent
where @code{@var{MY-LANGUAGE}} is the language's two-letter ISO
639 code.  This @command{make} call reduces the English
documentation files to bare skeleton files that are eventually
moved to the directory @file{Documentation/@/@var{MY-LANGUAGE}/},
exactly mimicking the directory and file structure of
@file{Documentation/en/}.

However, all include files still have the @file{en/} prefix,
making it load the English documentation.  If you plan to
translate, say, file @file{foo.itely}, and your language code is
@q{xy}; you should replace

@example
@@include@{en/foo.itely@}
@end example

@noindent
with

@example
@@include@{xy/foo.itely@}
@end example

@noindent
so that your translated text gets incorporated into the translated
document.

Finally, add entries for the new language to the following files:

@indentedblock
@file{python/langdefs.py}@*
@file{Documentation/lilypond-lang.init}@*
@file{Documentation/webserver/lilypond.org.htaccess}@*
@file{scripts/build/create-weblinks-iteci.py}@*
@file{ROADMAP}
@end indentedblock

A Texinfo language definition file is also needed:

@indentedblock
@file{Documentation/tex/txi-@var{MY-LANGUAGE}.tex}
@end indentedblock

The Texinfo distribution itself contains a large number of such
language definition files; take the one you need and simply copy
it.  If you are translating to a language for which no such file
is available and you are going to write it, please contribute it
to the Texinfo project, too!


@node Documentation translation details
@subsection Documentation translation details

Please follow all the instructions with care to ensure quality work.

All files should be encoded in UTF-8.


@node Files to be translated
@unnumberedsubsubsec Files to be translated

A translation of file @file{Documentation/@/en/@/foo/@/bar.baz}
should be stored in file
@file{Documentation/@/@var{MY-LANGUAGE}/@/foo/@/bar.baz}.
Unmentioned files should not be translated.

The table below list recommended priorities (lower values mean
higher priority) of files to be translated.  Files of
priority@tie{}1 should be submitted along all files generated by
starting a new language in the same commit and thus be a unique
patch.  Translation of files marked with priority@tie{}2 should be
committed to the git repository at the same time and thus sent in
a single patch.  Priority@tie{}1 files are required before
requesting a language-specific mailing list
@code{lilypond-xyz@@gnu.org}.  Files marked with priority@tie{}3
or lower may be submitted individually.  For knowing how to commit
your work to the git repository, preferably as a Merge Request,
@pxref{Working with source code}.

@strong{Only add translated files to the git repository!}  All
other, untranslated files can be safely deleted.  If necessary,
skeleton files can be regenerated by calling the
@command{new-lang} make target again (this doesn't overwrite
existing files).

@indentedblock
@raggedright
@multitable @columnfractions 0.02 0.98
@item 1
  @tab The website: @file{web.texi},
  @file{web/@/introduction.itexi}, and
  @file{web/@/download.itexi}.  Additionally, also translate
  @file{macros.itexi} and @file{search-box.ihtml}.
@item 2
  @tab The tutorial: @file{web/@/manuals.itexi},
  @file{learning.tely}, @file{learning/@/installing.itely},
  @file{learning/@/tutorial.itely}, and
  @file{learning/@/common-notation.itely}.
@item 3
  @tab Fundamental concepts in
  @file{learning/@/fundamental.itely}, as well as
  @file{usage.tely}, @file{usage/@/running.itely},
  @file{usage/@/updating.itely}, and @file{web/@/community.itexi}.
@item 4
  @tab The Changes file: @file{changes.tely}.
@item 5
  @tab More useful information: @file{learning/@/tweaks.itely},
  @file{learning/@/templates.itely}, and
  @file{usage/@/suggestions.itely}.
@item 6
  @tab The Notation Reference: @file{notation.tely}, all of
  @file{notation/@/*.itely}, and the snippets' titles and
  descriptions.
@item 7
  @tab More tools: @file{usage/@/lilypond-book.itely} and
  @file{usage/@/external.itely}.
@item 8
  @tab The Essay and the guide to extend LilyPond:
  @file{essay.tely} and @file{essay/@/*.itely}, as well as
  @file{extending.tely} and @file{extending/@/*.itely}.
@item 9
  @tab The Music Glossary: @file{music-glossary.tely}.
@item 10
  @tab LilyPond Snippets: @file{snippets.tely}.  A large portion
  of them is also included in the NR.
@end multitable
@end raggedright
@end indentedblock

A special case is file
@file{Documentation/@/po/@/@var{MY-LANGUAGE}.po}, which holds strings
to translate.  Currently, there are two helper scripts that access
it during a documentation build:

@itemize
@item
@command{www_post.py}, to post-process HTML pages.  Some messages
to translate are in its module @file{postprocess_html.py}, and
strings in the @file{.po} file tagged with this file name have
priority@tie{}1 for translation.

@item
@command{lilypond-book}, to automatically translate comments
within @code{@@lilypond} blocks.  In the @file{.po} file, such
strings are tagged with @q{(comment)}, and translating such
strings has a very low priority.

Strings tagged with other markers like @q{(variable)} and
@q{(context id)} can be safely ignored for the time being; the
same is true for strings tagged as being a @code{@@node} or a
sectioning command like @code{@@appendix}.

Note, however, that this @command{lilypond-book} feature is
currently broken.
@end itemize

Do not mix up the @file{Documentation/po/} and @file{po/}
directories!  The latter holds translations of messages emitted by
@command{lilypond} (the program) and various other tools; they are
maintained externally by the
@uref{https://translationproject.org/domain/lilypond.html,Free
Translation Project}.


@node Translating the website and other Texinfo documentation
@unnumberedsubsubsec Translating the website and other Texinfo documentation

Every piece of text should be translated in the source file, except
Texinfo comments, text in @code{@@lilypond} blocks and a few cases
mentioned below.

Node names are not translated, only the section titles are.
That is, every piece in the original file like

@example
@@node Foo bar
@@@var{section_command} Bar baz
@end example

@noindent
should be translated as

@example
@@node Foo bar
@@@var{section_command} @var{translation of Bar baz}
@end example

The argument of @code{@@rglos} commands and the first argument of
@code{@@rglosnamed} commands must not be translated, as it is the node
name of an entry in the Music Glossary.

Every time you translate a node name in a cross-reference, i.e.,
the argument of commands like @code{@@ref} or @code{@@rprogram}
(@pxref{Cross-references} for the complete list) or the first
argument of their @code{@@...named} variants, you should make sure
the target node is defined in the correct source file.  If you do
not intend to translate the target node right now, you should at
least write the node definition in the expected source file and
define all its parent nodes; for each node you have defined this
way but have not translated, insert a line that contains
@code{@@untranslated}.  That is, you should end up for each
untranslated node with something like

@example
@@node Foo bar
@@@var{section_command} @var{translation of Bar baz}

@@untranslated
@end example

@noindent
(the @code{new-lang} target does this in the skeleton files).

Please consider that it may not make sense to translate everything
in some Texinfo files, and that you may deviate from the original
text if necessary or useful.  For instance, in the translation of
the website section @qq{Community}, you may add information on the
community in your language and give links to existing public
forums or mailing lists.

@itemize
@item @rweb{Bug reports}: this page should be translated only if you
know that every bug report sent on your language's mailing list or
forum will be handled by someone who will translate it to English
and send it to @code{bug-lilypond} or add an issue in the tracker,
then translate back the reply from developers.  [Today, with the
help of automatic translators available in the internet, this is
less of a concern.]

@item @rweb{Help us}: this page should be translated very freely,
and possibly not at all -- a translation makes only sense if there
are enough people interested in contributing language-specific
documentation work.  For actually working on the code you have to
communicate with the developers in English.
@end itemize

@noindent
In any case, please mark in your work the sections which do not result
from the direct translation of a piece of English translation, using
comments, i.e., lines starting with @samp{@@c}.

Some pieces of text manipulated by build scripts that appear in
the output are translated in a @file{.po} file; this has been
discussed in the previous section.

Take care of using typographic rules for your language, especially in
@file{macros.itexi}.

If you wonder whether a word, phrase or larger piece of text should be
translated, whether it is an argument of a Texinfo command or a small
piece sandwiched between two Texinfo commands, try to track whether and
where it appears in PDF and/or HTML output as visible text.  This piece
of advice is especially useful for translating @file{macros.itexi}.

Please keep verbatim copies of music snippets (in @code{@@lilypond}
blocks).  However, some music snippets containing text that shows in
the rendered music, and sometimes translating this text really helps
the user to understand the documentation; in this case, and only in
this case, you may as an exception translate text in the music
snippet, and then you must add a line immediately before the
@code{@@lilypond} block, starting with

@example
@@c KEEP LY
@end example

@noindent
Otherwise the music snippet would be reset to the same content as
the English version at next @command{make snippet-update} run --
@pxref{Updating documentation translation}.

When you encounter

@example
@@lilypondfile[...,texidoc,...]@{@var{filename.ly}@}
@end example

@noindent
in the source, open
@file{Documentation/@/snippets/@/@var{filename}.ly}, translate the
@code{texidoc} header field it contains, wrap it with
@code{texidoc@var{MY-LANGUAGE} = "..."}, and write it into
@file{Documentation/@/@var{MY-LANGUAGE}/@/texidocs/@/@var{filename}.texidoc}.
Additionally, you may translate the snippet's title in the
@code{doctitle} header field in case @code{doctitle} is a fragment
option used in @code{@@lilypondfile}; you can do this exactly the
same way as @code{texidoc}.  For instance,
@file{Documentation/@/es/@/texidocs/@/@var{filename}.texidoc} may
contain

@example
doctitlees = "Spanish title baz"
texidoces = "
Spanish translation blah
"
@end example

The argument to @code{doctitle@var{XX}} must not contain a line
break; it is directly passed on to Texinfo, expecting the title on
single line (which gets typeset in more than a single line if
necessary, though).

@code{@@example} blocks need not be verbatim copies; it often
makes sense to translate variable names, file names, and comments.

Finally, please carefully apply every rule exposed previously;
@pxref{Texinfo introduction and usage policy}, and
@ref{Documentation policy}.  If one of these rules conflicts with
a rule specific to your language, please ask on the
@email{lilypond-devel@@gnu.org} list.


@node Adding a Texinfo manual
@unnumberedsubsubsec Adding a Texinfo manual

In order to start translating a new manual you might use the
skeleton files generated by the @code{new-lang} make target,
@pxref{Starting translation in a new language}.  You might also
copy the corresponding English files to your language directory
instead and translate them.

For example, if you want to translate the first chapter of the
Learning Manual:

@example
cp Documentation/en/learning.tely \
     Documentation/@var{MY-LANGUAGE}/learning.tely
cp Documentation/en/learning/tutorial.itely \
     Documentation/@var{MY-LANGUAGE}/learning/tutorial.itely
@end example


@node Documentation translation maintenance
@subsection Documentation translation maintenance

Several tools have been developed to make translations maintenance
easier.  These helper scripts make use of the power of git, the
version control system used for LilyPond development.

You should use them whenever you would like to update the
translation in your language, which you may do at the frequency
that fits your and your co-translators' respective available times.
In the case your translation is up-to-date (which you can discover
in the first subsection below), it is enough to check its state
every one or two weeks.  If you feel overwhelmed by the quantity
of documentation to be updated, @pxref{Maintaining without
updating translations}.


@macro seeCommittishesUpdate{}
@warning{do not forget to update the committish in each file you
have completely updated, @pxref{Updating translation
committishes}.}
@end macro

@node Check state of translation
@unnumberedsubsubsec Check state of translation

@warning{Translation helper scripts will work only if you have
configured LilyPond to be built in-tree, @pxref{Running autogen}.}

First pull from the git repository -- @pxref{Git cheat sheet}, but
@strong{do not} rebase unless you are sure to master the
translation state checking and updating system -- then
@command{cd} into @file{Documentation/} (or at top of the source
tree, replace @command{make} with @command{make -C Documentation})
and run

@example
make ISOLANG=@var{MY-LANGUAGE} check-translation
@end example

@noindent
This presents a diff of the original files since the most recent
revision of the translation and prints it to terminal output.
Usually you'll want to pass this output to a terminal pager
like @command{less} in order to scroll the diff up and down:

@example
make ISOLANG=@var{MY-LANGUAGE} check-translation | less -R
@end example

To check a single file, @command{cd} into @file{Documentation/}
and run

@example
make TRANSLATION_FILES=@var{MY-LANGUAGE}/@var{manual}/@var{foo}.itely check-translation
@end example

@noindent
In case this file has been renamed since you last updated the
translation, you should specify both old and new file names, e.g.,
@code{TRANSLATION_FILES=@var{MY-LANGUAGE}/@/@{@var{manual},user@}/@/@var{foo}.itely}.

To see only which files need to be updated, do

@example
make ISOLANG=@var{MY-LANGUAGE} check-translation | grep -n 'diff --git'
@end example

The @option{-n} option of @command{grep} will print the line
number of each occurrence, which can be used to estimate the
length of each diff and the amount of work required.

To avoid printing terminal color control characters, which is
often desirable when you redirect output to a file, run

@example
make ISOLANG=@var{MY-LANGUAGE} NO_COLOR=1 check-translation
@end example

You can see the diffs generated by the commands above as changes that
you should make in your language to the existing translation, in order
to make your translation up to date.

@seeCommittishesUpdate

@morerefs
@ref{Maintaining without updating translations}.
@endmorerefs

@node Updating documentation translation
@unnumberedsubsubsec Updating documentation translation

Instead of running @code{check-translation}, you may want to
execute @code{update-translation}, which will run your favorite
text editor to update files.  First, make sure the environment
variable @code{EDITOR} is set to a text editor command, then run
from @file{Documentation/}

@example
make ISOLANG=@var{MY-LANGUAGE} update-translation
@end example

@noindent
or, to update a single file,

@example
make TRANSLATION_FILES=@var{MY-LANGUAGE/@var{manual}/foo.itely} update-translation
@end example

For each file to be updated, @code{update-translation} will open your
text editor with this file and a diff of the file in English; if the
diff cannot be generated or is bigger than the file in English itself,
the full file in English will be opened instead.

@seeCommittishesUpdate

@file{.po} message catalogs in @file{Documentation/@/po/} may be
updated by changing to either directory @file{Documentation/} or
@file{Documentation/@/po/} and issuing

@example
make po-update
@end example

However, this make target doesn't work properly right now.

@warning{if you run @code{po-update} and somebody else does the
same and pushes before you push or send a patch to be applied to
the git repository, there will be a conflict when you pull.}

Updating music snippets can quickly become cumbersome, as most
snippets should be identical in all languages.  Fortunately, there
is a script that can do this odd job for you (to be run from
@file{Documentation/}):

@example
make ISOLANG=@var{MY-LANGUAGE} snippet-update
@end example

This make target calls a script to overwrite music snippets in all
@file{.itely} files in the @file{@var{MY-LANGUAGE}/} subdirectory
with music snippets taken from the @file{en/} subdirectory.  It
ignores skeleton files and doesn't modify music snippets that are
preceded by a line starting with @code{@@c KEEP LY}.  It reports
an error for each @file{.itely} file that has not the same music
snippet count in both languages.  Always use this script with a
lot of care, i.e., run it on a clean git working tree, and check
the changes it made with @command{git diff} before committing!  If
you don't do so, some @code{@@lilypond} snippets might be broken
or make no sense in their context.

@morerefs
@ref{Maintaining without updating translations},
@ref{Adding and editing snippets}.
@endmorerefs


@node Updating translation committishes
@unnumberedsubsubsec Updating translation committishes

At the beginning of each translated file (except for @file{.po}
files), there is a @dfn{committish} (i.e., an SHA-1 tag consisting
of 40 hexadecimal digits that uniquely identify a specific commit
in a git repository) to represent the revision of the sources that
you have used to translate this file from the file in English.

When you have pulled and updated a translation, it is very
important to update this committish in the files you have
completely updated (and only these); to do this, first commit
possible changes to any documentation in English which you are
sure to have done in your translation as well, then replace in the
up-to-date translated files the old committish by the committish
of the latest commit, which can be obtained by doing

@example
git rev-list HEAD | head -1
@end example

@c http://lists.gnu.org/archive/html/lilypond-devel/2009-01/msg00245.html
@c contains a helper script which could be used to perform massive
@c committish updates.

Most of the changes in LilyPond Wiki snippets included in the
documentation concern the syntax, not the description inside
@code{texidoc="..."}.  This implies that sometimes you will have
to update only the committish of the matching @code{.texidoc} file
and nothing else.  It can be a tedious work if there are many
snippets to be marked as up do date; you can use the following
command to update the committishes at once:

@example
cd Documentation/@var{MY-LANGUAGE}/texidocs
sed -i -r 's/[0-9a-z]@{40@}/@var{NEW-COMMITTISH}/' *.texidoc
@end example

@morerefs
@ref{LilyPond Wiki work}.
@endmorerefs


@node Maintaining without updating translations
@unnumberedsubsubsec Maintaining without updating translations

Keeping translations up to date if the English documentation has
been heavily changed is a hard task, especially when a lot of
contributors submit changes.

It is possible -- and even recommended -- to perform some maintenance
that keeps translated documentation usable and eases future translation
updating.

The following tasks are listed in decreasing priority order; a
rationale is given after the list.

@enumerate
@item
Update @file{macros.itexi}.  For each obsolete macro definition,
if it is possible to update macro usage in documentation with an
automatic text or regexp substitution, do it and delete the macro
definition from @file{macros.itexi}; otherwise, mark this macro
definition as obsolete with a comment, and keep it in
@file{macros.itexi} until the documentation translation has been
updated and no longer uses this macro.

@item
Update @file{.tely} files completely with @command{make
check-translation} -- you may want to redirect output to a file
because of overwhelming output, or directly call the
@command{check-translation.py} script on individual files,
@pxref{Check state of translation}.

@item
In @file{.itely} files, match sections and @code{.itely} file
names with those from the English documentation files, which
possibly involves moving the contents of complete node blocks
between files (without updating the documentation itself).  In
other words, the @q{game} is to find out where each section has
been moved to.  In case there are completely new sections, copy
@code{@@node} and @code{@@section} commands from the English
documentation files and add the marker for untranslated status
(@code{@@untranslated}, on a line of its own).  Note that it is
often not possible to exactly match subsections or subsubsections
of the English documentation when its contents has been deeply
revised; in this case, keep obsolete (sub)subsections in the
translation and mark them with a line @code{@@c obsolete} just
before the node.

The Emacs editor with its Texinfo mode makes this step easier;
here are some tips in case you are using it.

@itemize
@item
Without the AUCTeX package for Emacs installed, the key sequence
@key{C-c C-s} shows the structure of the current Texinfo file in a
new buffer called @code{*Occur*}.  To show the structure of two
files simultaneously, first split the Emacs window in 4@tie{}tiles
(with @key{C-x@tie{}1} and @key{C-x@tie{}2}), then press @key{C-c
C-s} to show the structure of one file (e.g., the translated
file), copy the contents of @code{*Occur*} into the
@code{*Scratch*} buffer, then press @key{C-c C-s} for the other
file.

If you happen to have AUCTeX installed, there is a function for
this, which you can call with @key{M-x texinfo-show-structure}.
You can also create a key binding in your @file{~/.emacs}
configuration file by adding the four following lines:

@example
(add-hook 'Texinfo-mode-hook
          '(lambda ()
             (define-key Texinfo-mode-map "\C-cs"
              'texinfo-show-structure)))
@end example

@noindent
After restarting Emacs you can then obtain the structure in the
@code{*Occur*} buffer with @key{C-c@tie{}s}.

@item
Moving to the next or previous node can be easily done with
incremental search: press @key{C-s} and type @code{node} (or
@key{C-s @@node} if the text contains the word @q{node}), then
press @key{C-s} to move to the next node or @key{C-r} to move to
the previous node.  Similar operation can be used to move to the
next or previous section.  Note that every cursor move exits
incremental search, and hitting @key{C-s} twice starts incremental
search with the text entered in previous incremental search.

@item
Moving a whole node (or even a sequence of nodes): jump to
beginning of the node (quit incremental search by pressing an
arrow), press @key{C-SPACE} to set a mark, press @key{C-s node}
and repeat @key{C-s} until you have selected enough text, cut it
with @key{C-w} or @key{C-x}, jump to the right place (moving
between nodes with the previous hint is often useful) and paste
with @key{C-y} or @key{C-v}.
@end itemize

@item
While working on @file{Documentation/@/po/@/@var{MY-LANGUAGE}.po}
it is recommended not to update strings located in English
documentation files that are actively revised.  Instead, wait
until the @q{dust has settled} to avoid doing the work more than
once.

@item
Check and fix broken cross-references by changing to directory
@file{Documentation/} and running

@example
make ISOLANG=@var{MY-LANGUAGE} check-xrefs
make ISOLANG=@var{MY-LANGUAGE} fix-xrefs
@end example

@noindent
This step requires a successful in-tree documentation build (with
@command{make doc}).  Some cross-references might be broken
because they point to nodes that exist in the English
documentation, and which have not been added to the translation.
In this case, do not fix the cross-reference but keep it
@q{broken} so that the resulting HTML link will miss the exact
spot in an existing page but still point to this page.
@end enumerate

@subsubheading Rationale

You may wonder if it would not be better to leave translations
as-is until you can really start updating translations.  There are
several reasons to do these maintenance tasks as soon as possible.

@itemize
@item
The work must be done sooner or later anyway (before updating the
translation of documentation contents), and in most cases it is
not needed to repeat the process later since sections in the
English documentation are mostly revised once.  Of course, this
might not be true sometimes, and then you really have to repeat
the process.

@item
It makes the translation take advantage of the new documentation
structure, which is better than staying with the old one.

@item
Moving and renaming sections to match the sectioning of English
documentation simplifies future updating work: it allows updating
the translation using a side-by-side comparison, without bothering
whether cross-reference names already exist in the translation.

@item
Each maintenance task except @q{Updating @file{.po} files} can be
done by the same person for all languages, which saves overall
time spent by translators to achieve this task: the node names are
in English, so @emph{you} can do it just fine.
@end itemize


@node Technical background
@subsection Technical background

A number of Python scripts handle parts of the documentation
translation process; they are located in the
@file{scripts/@/auxiliar/} directory.

@itemize
@item @file{check_translation.py} --
show diff to update a translation,
@item @file{texi-langutils.py} --
parse Texinfo files to make message catalogs and extract Texinfo
skeleton files,
@item @file{update-snippets.py} --
synchronize @file{.ly} snippets with those from the English
documentation.
@end itemize

Python modules used by scripts in @file{scripts/@/auxiliar/} or
@file{scripts/@/build/} (but not by installed Python scripts) are
located in the @file{python/@/auxiliar/} directory:

@itemize
@item @file{buildlib.py} --
common functions (read piped output of a shell command, use git, etc.),
@item @file{postprocess_html.py} (imported by @file{www_post.py}) --
add footer and tweak links in HTML pages.
@end itemize

And finally there is
@itemize
@item @file{python/langdefs.py} --
language definitions module.
@end itemize
