GNU LilyPond Contributor's Guide: 5.5 Fixing snippets in LilyPond sources

## 5.5 Fixing snippets in LilyPond sources

In case some snippet from ‘`input/lsr`’ cause the documentation compilation to fail, the following steps should be followed to fix it reliably.

1. Look up the snippet filename ‘`foo.ly`’ in the error output or log, then fix the file ‘`input/lsr/foo.ly`’ to make the documentation build succesfully.
2. Determine where it comes from by looking at its first line, e.g. run

   >     head -1 input/lsr/foo.ly

3. In case the snippet comes from LSR, apply the fix to the snippet in LSR and send a notification email to a LSR editor with CC to the development list – see Adding and editing snippets. The failure may sometimes not be caused by the snippet in LSR but by the syntax conversion made by `convert-ly`; in this case, try to fix `convert-ly` or report the problem on the development list, then run `makelsr.py` again, see LSR to Git. In some cases, when some features has been introduced or vastly changed so it requires (or takes significant advantage of) important changes in the snippet, it is simpler and recommended to write a new version of the snippet in ‘`input/new`’, then run `makelsr.py`.
4. In case the snippet comes from ‘`input/new`’, apply in ‘`input/new/foo.ly`’ the same fix you did in ‘`input/lsr/foo.ly`’. In case the build failure was caused by a translation string, you may have to fix ‘`input/texidocs/foo.texidoc`’ instead.
5. In any case, commit all changes to Git.

#### Contributor’s Guide