Refine check-translation error message

[lilypond.git] / Documentation / es / user / working.itely

@c -*- coding: utf-8; mode: texinfo; -*-
@c This file is part of lilypond.tely
@ignore
    Translation of GIT committish: dc78324e8424699ec17df064941c0c787d4eb91c

    When revising a translation, copy the HEAD committish of the
    version that you are working on.  See TRANSLATION for details.
@end ignore

@node Working on LilyPond projects
@chapter Working on LilyPond projects

Esta sección explica cómo resolver o evitar ciertos problemas comunes.
Si tiene experiencia en programación muchos de estos
consejos pueden parecer obvios, pero aún así le recomendamos
que lea este capítulo.


@menu
* Suggestions for writing LilyPond files::  
* Saving typing with identifiers and functions::  
* Style sheets::                
* Updating old files::          
* Troubleshooting (taking it all apart)::  
* Minimal examples::            
@end menu


@node Suggestions for writing LilyPond files
@section Suggestions for writing LilyPond files

En este momento está preparado para comenzar a escribir archivos de LilyPond más grandes -- no sólo los
pequeños ejemplos que aparecen en el tutorial, sino piezas completas --. Pero ¿cómo debe proceder
para hacerlo?

En la medida en que LilyPond entienda sus archivos y produzca la salida que usted
pretendía, realmente no importa mucho qué aspecto tengan sus archivos.  Sin embargo
existen algunas otras cosas a tener en cuenta cuando se escriben archivos de LilyPond.

@itemize @bullet
@item ¿Qué ocurre si comete un fallo?  La estructura de un archivo
lilypond puede hacer que ciertos errores se hagan más fáciles (o más difíciles) de encontrar.

@item ¿Qué ocurre si quiere compartir sus archivos con otras personas?
De hecho, ¿y si quiere alterar sus propios archivos después de algunos años?
Algunos archivos de lilypond se comprenden a primera vista;
otros pueden tenerle rascándose la cabeza durante una hora.

@item ¿Qué ocurre si quiere actualizar su archivo de lilypond para poderlo usar con
una versión más reciente del programa?  La sintaxis de la entrada se modifica
de forma ocasional según lilypond se va perfeccionando.  Casi todos los cambios se pueden
hacer de forma automática con @code{convert-ly}, pero algunos podrían necesitar de una
ayuda manual.  Los archivos de LilyPond se pueden estructurar para que sean
más fáciles (o más difíciles) de actualizar.
@end itemize

@menu
* General suggestions::         
* Typesetting existing music::  
* Large projects::              
@end menu


@node General suggestions
@subsection General suggestions

Presentamos algunas sugerencias que pueden serle de ayuda para evitar
o corregir problemas:

@itemize @bullet
@item @strong{Incluya los números de @code{\version} en todos los archivos}.  Dése cuenta de que todas las
plantillas contienen una cadena como @code{\version "2.11.15"}.  Le recomendamos
mucho que siempre incluya la @code{\version}, sin importar cuán
pequeño pueda ser su archivo.  Desde la experiencia personal podemos decirle que es bastante frustrante
intentar recordar el número de versión de LilyPond que estaba usando hace unos años.
@code{convert-ly} requiere que declare qué versión de LilyPond utilizó.

@item @strong{Incluya comprobaciones}: @ref{Bar check}, @ref{Octave check} y
@ref{Barnumber check}.  Si
incluye comprobaciones de vez en cuando, en caso de que cometa un error podrá localizarlo mucho más rápidamente.
¿Con qué frecuencia es @q{de vez en cuando}?  Depende de la complejidad
de la música.  Para una música muy sencilla, quizá tan sólo una o dos veces.  Para
una música muy compleja, quizá a cada compás.

@item @strong{Un compás por cada línea de texto}.  Si hay algo muy complicado, ya sea
en la propia música
o en la salida que desea producir, a menudo conviene escribir un solo compás
por cada línea.  El ahorro en espacio de pantalla que se obtiene al amontonar ocho compases por línea no merece la pena
si luego tiene que @q{depurar} los archivos.

@item @strong{Comente los archivos}.  Utilice o números de compás (de vez en cuando)
o referencias a temas musicales (@q{segundo tema de los violines,} @q{cuarta
variación,} etc.).  Puede que no necesite comentarios cuando introduce una pieza por vez primera,
pero si quiere volver a ella o modificar algo al cabo de dos o tres años,
y también si le pasa la fuente a un amigo, será
todo un desafío determinar sus intenciones o de qué manera estaba estructurado el archivo si no le añadió los comentarios.

@item @strong{Aplique márgenes a las llaves}.  Muchos problemas están causados por una falta de
equilibrio en el número de @code{@{} y @code{@}}.

@item @strong{Escriba las duraciones explícitamente} al comienzo de las secciones
e identificadores.  Si especifica @code{c4 d e} al principio de una frase
(en lugar de sólo @code{c d e}) se puede ahorrar problemas
si reelabora la música más tarde.

@item @strong{Separe los trucos} de las definiciones musicales.  Consulte
@ref{Saving typing with identifiers and functions} y
@ref{Style sheets}.

@end itemize


@node Typesetting existing music
@subsection Typesetting existing music

Si está introduciendo música a partir de una partitura existente (es decir, tipografiando una hoja
de música ya impresa),

@itemize @bullet

@item Introduzca un sistema del manuscrito (la copia física) cada vez (pero mantenga
la práctica de escibir un compás por línea de texto), y
compruebe cada sistema cuando lo haya terminado.  Puede usar el comando
@code{showLastLength} para acelerar el proceso -- ver
@ref{Skipping corrected music} -- .

@item Defina @code{mBreak = @{ \break @}} e inserte @code{\mBreak}
dentro del archivo de entrada donde el manuscrito tenga un saldo de línea.  De esta forma
le resultará mucho más fácil comparar la música de LilyPond con la original.
Cuando haya terminado de revisar su partitura podrá
definir @code{mBreak = @{ @}} para quitar todos esos saltos de línea.  Así
permitirá a LilyPond colocar los saltos donde éste lo estime más oportuno.

@end itemize


@node Large projects
@subsection Large projects

Al trabajar en proyecto grande se hace esencial tener una estructura clara en los archivos de lilypond.

@itemize @bullet

@item @strong{Utilice un identificador para cada voz}, con un mínimo de
estructura dentro de la definición.  La estructura de la sección
@code{\score} es la que cambiará con mayor probabilidad; por contra, es
extremadamente improbable que cambie la definición de @code{violin} en
versiones nuevas de LilyPond.

@example
violin = \relative c'' @{
g4 c'8. e16
@}
...
\score @{
  \new GrandStaff @{
    \new Staff @{
      \violin
    @}
  @}
@}
@end example

@item @strong{Separe los trucos de las definiciones musicales}.  Ya se mencionó
en @ref{General suggestions}, pero para proyectos
grandes es vital.  Quizá tengamos que cambiar la
definición de @code{fthenp}, pero en ese caso sólo lo tendremos que
hacer una vez, y aún podremos evitar tocar nada dentro de @code{violin}.

@example
fthenp = _\markup@{
  \dynamic f \italic \small @{ 2nd @} \hspace #0.1 \dynamic p @}
violin = \relative c'' @{
g4\fthenp c'8. e16
@}
@end example

@end itemize


@node Saving typing with identifiers and functions
@section Saving typing with identifiers and functions

@cindex variables
@cindex identificadores

Llegado a este punto, usted ha visto cosas de este tipo:

@lilypond[quote,verbatim,ragged-right]
hornNotes = \relative c'' { c4 b dis c }
\score {
  {
    \hornNotes
  }
}
@end lilypond

Incluso se dará cuenta de que esto puede ser útil en música minimalista:

@lilypond[quote,verbatim,ragged-right]
fragA = \relative c'' { a4 a8. b16 }
fragB = \relative c'' { a8. gis16 ees4 }
violin = \new Staff { \fragA \fragA \fragB \fragA }
\score {
  {
    \violin
  }
}
@end lilypond

Sin embargo también puede usar estos identificadores (que también se conocen como
variables, macros o comandos definidos por el usuario) para hacer trucos:

@lilypond[quote,verbatim,ragged-right]
dolce = \markup{ \italic \bold dolce }
padText = { \once \override TextScript #'padding = #5.0 }
fthenp=_\markup{ \dynamic f \italic \small { 2nd } \hspace #0.1 \dynamic p }
violin = \relative c'' {
  \repeat volta 2 {
    c4._\dolce b8 a8 g a b |
    \padText
    c4.^"hi there!" d8 e' f g d |
    c,4.\fthenp b8 c4 c-. |
  }
}
\score {
  {
    \violin
  }
\layout{ragged-right=##t}
}
@end lilypond

Obviamente estos identificadores son útiles para ahorrar tecleo.
Pero son dignos de tener en cuenta incluso si se van a utilizar una sola vez:
reducen la complejidad.  Examinemos
el ejemplo anterior reescrito sin ningún identificador.
Encontrará que es mucho más difícil de leer, sobre todo la última línea.

@example
violin = \relative c'' @{
  \repeat volta 2 @{
    c4._\markup@{ \italic \bold dolce @} b8 a8 g a b |
    \once \override TextScript #'padding = #5.0
    c4.^"hi there!" d8 e' f g d |
    c,4.\markup@{ \dynamic f \italic \small @{ 2nd @}
      \hspace #0.1 \dynamic p @} b8 c4 c-. |
  @}
@}
@end example

Hasta ahora hemos contemplado la sustitucion estática: cuando LilyPond
se encuentra con @code{\padText}, lo sustituye con aquello que
hemos definido que sea (es decir, todo lo que está a la derecha de
@code{padtext=}).

LilyPond también puede manejar sustituciones no estáticas (piense en ellas
como en funciones).

@lilypond[quote,verbatim,ragged-right]
padText =
#(define-music-function (parser location padding) (number?)
  #{
    \once \override TextScript #'padding = #$padding
  #})

\relative c''' {
  c4^"piu mosso" b a b
  \padText #1.8
  c4^"piu mosso" d e f
  \padText #2.6
  c4^"piu mosso" fis a g
}
@end lilypond

La utilización de identificadores también es una buena forma de reducir el trabajo si
la sintaxis de entrada de LilyPond cambia (ver @ref{Updating old files}).  Si
tiene una sola definición (como p.ej. @code{\dolce}) para todos sus
archivos (ver @ref{Style sheets}), y después la sintaxis se modifica, sólo tendrá
que actualizar su definición @code{\dolce} única,
en lugar de tener que hacer cambios en cada uno de los archivos @code{.ly}.


@node Style sheets
@section Style sheets

La salida que produce LilyPond se puede modificar profundamente; consulte
@ref{Tweaking output} para leer detalles sobre este asunto.  Pero ¿qué ocurre si tiene muchos
archivos a los que les quiere aplicar sus porpios trucos?  O ¿qué ocurre si, sencillamente,
quiere separar los trucos de la propia música?  Todo esto es bastante fácil de conseguir.

Veamos un ejemplo.  No se preocupe si no entiende
las partes que tienen todos los @code{#()}.  Esto se explicará en
@ref{Advanced tweaks with Scheme}.

@lilypond[quote,verbatim,ragged-right]
mpdolce = #(make-dynamic-script (markup #:hspace 1 #:translate (cons 5 0)
  #:line(#:dynamic "mp" #:text #:italic "dolce" )))
tempoMark = #(define-music-function (parser location markp) (string?)
#{
  \once \override Score . RehearsalMark #'self-alignment-X = #left
  \once \override Score . RehearsalMark #'extra-spacing-width = #'(+inf.0 . -inf.0)
  \mark \markup { \bold $markp }
#})

\relative c'' {
  \tempo 4=50
  a4.\mpdolce d8 cis4--\glissando a | b4 bes a2
  \tempoMark "Poco piu mosso"
  cis4.\< d8 e4 fis | g8(\! fis)-. e( d)-. cis2
}
@end lilypond

Existen varios problemas con la salida que se superpone; los arreglaremos utilizando
las técnicas descritas en @ref{Moving objects}.  Pero también haremos algo respecto a
las definiciones @code{mpdolce} y @code{tempoMark}.  Éstas producen la salida que
deseamos, pero quizá las querríamos utilizar en otra pieza.
Podríamos simplemente copiarlas y pegarlas al principio de cada archivo,
pero sería bastente molesto.  También hace que se queden las definiciones
a la vista dentro de nuestros archivos de música, y yo personalmente encuentro
todos los @code{#()} bastante poco estéticos.  Los vamos a esconder dentro de otro archivo:

@example
%%% guardar esto en un archivo de nombre "definiciones.ly"
mpdolce = #(make-dynamic-script (markup #:hspace 1 #:translate (cons 5 0)
  #:line(#:dynamic "mp" #:text #:italic "dolce" )))
tempoMark = #(define-music-function (parser location markp) (string?)
#@{
  \once \override Score . RehearsalMark #'self-alignment-X = #left
  \once \override Score . RehearsalMark #'extra-spacing-width = #'(+inf.0 . -inf.0)
  \mark \markup @{ \bold $markp @}
#@})
@end example

Ahora modificaremos la música (guardemos este archivo como @file{"musica.ly"}).

@c  We have to do this awkward example/lilypond-non-verbatim
@c  because we can't do the \include stuff in the manual.

@example
\include "definiciones.ly"

\relative c'' @{
  \tempo 4=50
  a4.\mpdolce d8 cis4--\glissando a | b4 bes a2
  \once \override Score.RehearsalMark #'padding = #2.0
  \tempoMark "Poco piu mosso"
  cis4.\< d8 e4 fis | g8(\! fis)-. e( d)-. cis2
@}
@end example

@lilypond[quote,ragged-right]
mpdolce = #(make-dynamic-script (markup #:hspace 1 #:translate (cons 5 0)
  #:line(#:dynamic "mp" #:text #:italic "dolce" )))
tempoMark = #(define-music-function (parser location markp) (string?)
#{
  \once \override Score . RehearsalMark #'self-alignment-X = #left
  \once \override Score . RehearsalMark #'extra-spacing-width = #'(+inf.0 . -inf.0)
  \mark \markup { \bold $markp }
#})

\relative c'' {
  \tempo 4=50
  a4.\mpdolce d8 cis4--\glissando a | b4 bes a2
  \once \override Score.RehearsalMark #'padding = #2.0
  \tempoMark "Poco piu mosso"
  cis4.\< d8 e4 fis | g8(\! fis)-. e( d)-. cis2
}
@end lilypond

Eso tiene mejor aspecto, pero haremos algunos cambios más.  El glissando es difícil
de ver, así que lo haremos más grueso y lo acercaremos a las cabezas de las notas.  Pondremos
la indicación metronómica encima de la clave, en lugar de ir encima de la primera
nota.  Y por último, mi profesor de composición odia las indicaciones de compás @q{C},
así que la convertiremos en @q{4/4}.

Sin embargo, no debe cambiar el archivo @file{musica.ly}.  Sustituya nuestro archivo @file{definiciones.ly}
con éste:

@example
%%%  definiciones.ly
mpdolce = #(make-dynamic-script (markup #:hspace 1 #:translate (cons 5 0)
  #:line( #:dynamic "mp" #:text #:italic "dolce" )))
tempoMark = #(define-music-function (parser location markp) (string?)
#@{
  \once \override Score . RehearsalMark #'self-alignment-X = #left
  \once \override Score . RehearsalMark #'extra-spacing-width = #'(+inf.0 . -inf.0)
  \mark \markup @{ \bold $markp @}
#@})

\layout@{
  \context @{ \Score
    \override MetronomeMark #'extra-offset = #'(-9 . 0)
    \override MetronomeMark #'padding = #'3
  @}
  \context @{ \Staff
    \override TimeSignature #'style = #'numbered
  @}
  \context @{ \Voice
    \override Glissando #'thickness = #3
    \override Glissando #'gap = #0.1
  @}
@}
@end example

@lilypond[quote,ragged-right]
mpdolce = #(make-dynamic-script (markup #:hspace 1 #:translate (cons 5 0)
  #:line( #:dynamic "mp" #:text #:italic "dolce" )))
tempoMark = #(define-music-function (parser location markp) (string?)
#{
  \once \override Score . RehearsalMark #'self-alignment-X = #left
  \once \override Score . RehearsalMark #'extra-spacing-width = #'(+inf.0 . -inf.0)
  \mark \markup { \bold $markp }
#})

\layout{
  \context { \Score
    \override MetronomeMark #'extra-offset = #'(-9 . 0)
    \override MetronomeMark #'padding = #'3
  }
  \context { \Staff
    \override TimeSignature #'style = #'numbered
  }
  \context { \Voice
    \override Glissando #'thickness = #3
    \override Glissando #'gap = #0.1
  }
}

\relative c'' {
  \tempo 4=50
  a4.\mpdolce d8 cis4--\glissando a | b4 bes a2
  \once \override Score.RehearsalMark #'padding = #2.0
  \tempoMark "Poco piu mosso"
  cis4.\< d8 e4 fis | g8(\! fis)-. e( d)-. cis2
}
@end lilypond

¡Eso tiene un aspecto mucho mejor!  Ahora suponga que quier publicar esta
pieza.  A mi profesor de composición no le gustan las indicaciones de compás @q{C},
pero yo les tengo cierto cariño.  Copiaremos el archivo
actual @file{definiciones.ly} a @file{publicar-web.ly} y modificaremos
éste.  Como el propósito de esta música es producir un PDF que va a mostrarse
en la pantalla, también vamos a aumentar el
tamaño general de la salida.

@example
%%%  definiciones.ly
mpdolce = #(make-dynamic-script (markup #:hspace 1 #:translate (cons 5 0)
  #:line( #:dynamic "mp" #:text #:italic "dolce" )))
tempoMark = #(define-music-function (parser location markp) (string?)
#@{
  \once \override Score . RehearsalMark #'self-alignment-X = #left
  \once \override Score . RehearsalMark #'extra-spacing-width = #'(+inf.0 . -inf.0)
  \mark \markup @{ \bold $markp @}
#@})

#(set-global-staff-size 23)
\layout@{
  \context @{ \Score
    \override MetronomeMark #'extra-offset = #'(-9 . 0)
    \override MetronomeMark #'padding = #'3
  @}
  \context @{ \Staff
  @}
  \context @{ \Voice
    \override Glissando #'thickness = #3
    \override Glissando #'gap = #0.1
  @}
@}
@end example

@lilypond[quote,ragged-right]
mpdolce = #(make-dynamic-script (markup #:hspace 1 #:translate (cons 5 0)
  #:line( #:dynamic "mp" #:text #:italic "dolce" )))
tempoMark = #(define-music-function (parser location markp) (string?)
#{
  \once \override Score . RehearsalMark #'self-alignment-X = #left
  \once \override Score . RehearsalMark #'extra-spacing-width = #'(+inf.0 . -inf.0)
  \mark \markup { \bold $markp }
#})

#(set-global-staff-size 23)
\layout{
  \context { \Score
    \override MetronomeMark #'extra-offset = #'(-9 . 0)
    \override MetronomeMark #'padding = #'3
  }
  \context { \Voice
    \override Glissando #'thickness = #3
    \override Glissando #'gap = #0.1
  }
}

\relative c'' {
  \tempo 4=50
  a4.\mpdolce d8 cis4--\glissando a | b4 bes a2
  \once \override Score.RehearsalMark #'padding = #2.0
  \tempoMark "Poco piu mosso"
  cis4.\< d8 e4 fis | g8(\! fis)-. e( d)-. cis2
}
@end lilypond

Ahora, en la música, simplemente sustituyo
@code{\include "definiciones.ly"} por
@code{\include "publicar-web.ly"}.  Por supuesto, podríamos hacer esto aún más
práctico.  Podríamos hacer un archivo @file{definiciones.ly} que contuviera
solamente las definiciones de @code{mpdolce} y @code{tempoMark}, un archivo
@file{web-publish.ly} que contuviera solamente la sección @code{\layout}
que se mostró en el ejemplo, y un archivo @file{universidad.ly} que contendría
solamente los trucos para producir la salida que le gusta a mi
profesor.  La parte más alta de @file{musica.ly} tendría entonces este aspecto:

@example
\include "definiciones.ly"

%%%  ¡Quitar el comentario de una sola de estas líneas!
\include "publicar-web.ly"
%\include "universidad.ly"
@end example

Este enfoque puede ser útil incluso si va a producir sólo un conjunto de particellas.
Yo utilizo media docena de archivos de
@q{hojas de estilo} para mis proyectos.  Comienzo todos los archivos de música con
@code{\include "../global.ly"}, que contiene

@example
%%%   global.ly
\version "2.11.15"
#(ly:set-option 'point-and-click #f)
\include "../iniciar/iniciar-definiciones.ly"
\include "../iniciar/iniciar-disposicion.ly"
\include "../iniciar/iniciar-cabeceras.ly"
\include "../iniciar/iniciar-papel.ly"
@end example


@node Updating old files
@section Updating old files

La sintaxis de la entrada de LilyPond cambia de manera ocasional.  A
medida que el propio LilyPond mejora, la sintaxis (el lenguaje de la
entrada) se modifica en consonancia.  A veces estos cambios se hacen
para conseguir que la entrada sea más fácil de leer y escribir, y
otras veces estos cambios son para dar cabida a nuevas funcionalidades
de LilyPond.

LilyPond lleva incorporado un archivo que facilita esta actualización:
@code{convert-ly}.  Para ver detalles sobre cómo ejecutar este programa, consulte
@ref{Updating files with convert-ly}.

Desgraciadamente @code{convert-ly} no puede tratar todos los cambios en la entrada.
Se ocupa de los cambios sencillos de búsqueda y sustitución (como @code{raggedright}
que se convierte en @code{ragged-right}), pero algunos cambios son demasiado
complicados.  Los cambios de sintaxis que @code{convert-ly} es incapaz de manejar
se relacionan en @ref{Updating files with convert-ly}.

Por ejemplo, en la versión 2.4 y anteriores de LilyPond, los acentos y las letras no inglesas
se introducían utilizando LaTeX: por ejemplo,
@samp{No\"el} (que significa @q{Navidad} en francés).  En LilyPond 2.6 y siguientes, el carácter especial
@samp{ë} debe introducirse directamente en el archivo de LilyPond como un carácter
UTF-8.  @code{convert-ly} no puede cambiar todos los caracteres especiales de LaTeX
a caracteres de UTF-8; tendrá que actualizar manualmente
sus archivos de LilyPond antiguos.


@node Troubleshooting (taking it all apart)
@section Troubleshooting (taking it all apart)

Antes o después escribirá un archivo que LilyPond no podrá compilar.
Los mensajes que LilyPond proporciona pueden ayudarle a encontrar el
error, pero en muchos casos tendrá que llevar a cabo algún tipo de
investigación para determinar el origen del problema.

Las herramientas más poderosas para este cometido son el
comentario de una sola línea (indicado por @code{%}) y el comentario de bloque
(indicado por @code{%@{ ... %@}}).  Si no sabe dónde está
el problema, comience coviertiendo grandes secciones del
archivo de entrada en un comentario.  Después de eliminar una
sección convirtiéndola en un comentario, pruebe a compilar el
archivo otra vez.  Si funciona, entonces el problema debía estar
en la porción que había eliminado.  Si no funciona,
continúe eliminando material (transformándolo en comentarios)
hasta que tenga algo que funcione.

En un caso extremo podría terminar con sólo

@example
\score @{
  <<
    % \melodia
    % \harmonia
    % \bajo
  >>
  \layout@{@}
@}
@end example

@noindent
(en otras palabras: un archivo sin música)

Si ocurre esto, no abandone.  Descomente un trozo pequeño -- digamos
la parte del bajo -- y observe si funciona.  Si no es así,
transforme en comentarios toda la música del bajo (pero deje el
@code{\bajo} de la sección @code{\score} no comentado.

@example
bajo = \relative c' @{
%@{
  c4 c c c
  d d d d
%@}
@}
@end example

Ahora empiece poco a poco descomentando cada vez más fracciones de la
parte del @code{bajo} hasta que encuentre la línea del problema.

Otra técnica de depuración muy útil es la construcción de
@ref{Minimal examples}.


@node Minimal examples
@section Minimal examples

Un ejemplo mínimo es un ejemplo tan pequeño como sea posible.  Estos
ejemplos son mucho más fáciles de comprender que los ejemplos largos.  Los ejemplos
mínimos se utilizan para

@itemize
@item Informes de fallo
@item Solicitudes de ayuda a las listas de correo
@item Añadir ejemplos al @uref{http://lsr@/.dsi@/.unimi@/.it/,Repositorio de Fragmentos de Código de LilyPond}
@end itemize

Para construir un ejemplo que sea lo más pequeño posible, la regla es
bastante simple: quite todo lo que no sea necesario.  Al tratar de
quitar partes innecesarias de un archivo, es una buena idea convertir líneas en
comentarios en vez de borrarlas.  De esta forma, si descubre que en realidad
sí @emph{necesitaba} algunas de estas líneas, podrá descomentarlas y no tendrá que
teclearlas de nuevo partiendo de cero.

Existen dos excepciones a la regla del @qq{lo más pequeño posible}:

@itemize
@item Incluya el número de @code{\version}.
@item Si puede, ponga @code{\paper@{ ragged-right=##t @}} al principio del ejemplo.
@end itemize

En resumen, el objetivo de un ejemplo mínimo es que sea fácil de leer:

@itemize
@item Evite usar notas, tonalidades o compases demasiado complicados, a no ser que quiera
demostrar algo sobre el comportamiento de estos elementos precisamente.
@item No use comandos @code{\override} a no ser que ése sea el propósito del ejemplo.
@end itemize