@c -*- coding: utf-8; mode: texinfo; documentlanguage: es -*-
@c This file is part of extending.tely
@ignore
- Translation of GIT committish: 84e6243cfa30f294727192befbba5e746fec6d5f
+ Translation of GIT committish: 41c8bf63a7cc180746eace9b9e5278f541be0229
When revising a translation, copy the HEAD committish of the
version that you are working on. See TRANSLATION for details.
@end ignore
-@c \version "2.17.6"
+@c \version "2.19.2"
@node Interfaces para programadores
@chapter Interfaces para programadores
@item @code{@var{typeN?}}
@tab un @emph{predicado de tipo} de Scheme para el que @code{@var{argN}}
-debe devolver @code{#t}. Algunos de estos predicados se reconocen
-de forma especial por parte del analizador, véase más abajo.
+debe devolver @code{#t}.
+
También existe una forma especial @code{(@emph{predicate?}
@emph{default})} para especificar argumentos opcionales. Si el
-argumento actual no está presente cuando se ll ama a la función,
-el valor predeterminado se emplea en sustitución. Los valores
-predeterminados se evalúan en tiempo de definición (¡incluyendo
-los bloques de código de LilyPond!), de manera que se necesitamos
-un valor por omisión calculado en tiempo de ejecución, debemos
-escribir en su lugar un valor especial que podamos reconocer
-fácilmente. Si escribimos el predicado entre paréntesis pero no
-lo seguimos por el valor predeterminado, se usa @code{#f} como
-valor por omisión. Los valores por omisión no se verifican con
-@emph{predicate?} en tiempo de definición ni en tiempo de
-ejecución: es nuestra responsabilidad tratar con los valores que
-especifiquemos. Los valores por omisión que son expresiones
-musicales se copian mientras se establece @code{origin} al
-parámetro @code{location}.
+argumento actual no está presente cuando se ll ama a la función, el
+valor predeterminado se emplea en sustitución. Los valores
+predeterminados se evalúan en tiempo de definición (¡incluyendo los
+bloques de código de LilyPond!), de manera que se necesitamos un valor
+por omisión calculado en tiempo de ejecución, debemos escribir en su
+lugar un valor especial que podamos reconocer fácilmente. Si
+escribimos el predicado entre paréntesis pero no lo seguimos por el
+valor predeterminado, se usa @code{#f} como valor por omisión. Los
+valores por omisión no se verifican con @emph{predicate?} en tiempo de
+definición ni en tiempo de ejecución: es nuestra responsabilidad
+tratar con los valores que especifiquemos. Los valores por omisión
+que son expresiones musicales se copian mientras se establece
+@code{origin} al parámetro @code{location}.
@item @code{@var{cuerpo}}
@tab una secuencia de formas de Scheme que se evalúan ordenadamente; la
@end multitable
@noindent
-Ciertos predicados de tipo se manejan de forma especial por parte del
-analizador sintáctico ya que de otro modo éste no es capaz de
-reconocer los argumentos eficientemente. Actualmente son
-@code{ly:pitch?} y @code{ly:duration?}.
-
-La idoneidad de lpos argumentos para el resto de los predicados viene
-determinada mediante llamadas reales al predicado después de que
-LilyPond ya las ha convertido en una expresión de Scheme. Como
-consecuencia, el argumento se puede especificar en la sintaxis de
-Scheme si se desea (precedido de @code{#} o como resultado de haber
-llamado a una función de Scheme), pero LilyPond también convierte
-algunas construcciones de LilyPond en Scheme antes de hacer
-efectivamente la comprobación del predicado sobre ellas. Actualmente
-se encuentran entre ellas la música, los post-eventos, las cadenas
-simples (entrecomilladas o no), los números, los elementos de marcado
-y de listas de marcado, score (partitura), book (libro), bookpart
-(parte de libro), las definiciones de contexto y los bloques de
-definición de salida.
+La idoneidad de los argumentos para los predicados viene determinada
+mediante llamadas reales al predicado después de que LilyPond ya las
+ha convertido en una expresión de Scheme. Como consecuencia, el
+argumento se puede especificar en la sintaxis de Scheme si se desea
+(precedido de @code{#} o como resultado de haber llamado a una función
+de Scheme), pero LilyPond también convierte algunas construcciones de
+LilyPond en Scheme antes de hacer efectivamente la comprobación del
+predicado sobre ellas. Actualmente se encuentran entre ellas la
+música, los post-eventos, las cadenas simples (entrecomilladas o no),
+los números, los elementos de marcado y de listas de marcado, score
+(partitura), book (libro), bookpart (parte de libro), las definiciones
+de contexto y los bloques de definición de salida.
Para ciertos tipos de expresión (como la mayor parte de la música que
no está encerrada entre llaves) LilyPond necesita más allá de la
considerase un argumento opcional mediante la evaluación de su
predicado, LilyPond no podría recuperarse después de decidir que la
expresión no se corresponde con el parámetro. Así, ciertas formas de
-música necesitan ir encerradas entre llaves para que LilyPond pueda
-aceptarlas. Existen también otras ambigüedades que LilyPond resuelve
-mediante la comprobación con funciones de predicado: ¿es @samp{-3} un
-post-evento de digitación o un nnúmero negativo? ¿Es @code{"a" 4} en
-el modo de letra una cadena seguida por un número, o un evento de
-letra con la duración @code{4}? LilyPond lo decide preguntándole a
-los predicados. Ello significa que un debemos evitar los
-predicados permisivos como @code{scheme?} si tenemos en mente
-un uso particular en vez de una función de uso general.
+música necesitan ir encerradas entre llaves para poder considerarlas
+como aceptables bajo algunas circunstancias. LilyPond resuelve
+algunas otras ambigüedades mediante la comprobación con funciones de
+predicado: ¿es @samp{-3} un post-evento de digitación o un número
+negativo? ¿Es @code{"a" 4} en el modo de letra una cadena seguida por
+un número, o un evento de letra con la duración @code{4}? LilyPond
+prueba el predicado del argumento sobre diversas interpretaciones
+sucesivas hasta que lo consigue, con un orden diseñado para minimizar
+las interpretaciones poco consistentes y la lectura por adelantado.
+
+Por ejemplo, un predicado que acepta tanto expresiones musicales como
+alturas consideraría que @code{c''} es una altura en lugar de una
+expresión musical. Las duraciones o post-eventos que siguieran
+inmediatamente podrían no funcionar con dicha interpretación. Así
+pues, es mejor evitar los predicados excesivamente permisivos como
+@code{scheme?} cuando la aplicación requeriría tipos de argumento más
+específicos.
Para ver una lista de los predicados de tipo disponibles, consulte
@ruser{Predicados de tipo predefinidos}.
@item
Como un post-evento, que comienza explícitamente con un indicador de
dirección (a elegir entre @code{-}, @code{^} @w{y @code{_}}).
-Observe que se puede aceptar la devolución de un
-post-evento por parte de las funciones musicales que se llaman como
-música normal, lo que lleva a un resultado aproximadamente equivalente
-a
-@example
-s 1*0-\fun
-@end example
En este caso, no podemos usar una expresión musical @emph{abierta}
como último argumento, que terminaría en una expresión musical
Scheme para los argumentos antecedentes de las funciones de marcado
que toman un marcado como su último argumento.
+@funindex \markup
+@cindex markup macro
+@funindex interpret-markup
+Las instrucciones de marcado tienen un ciclo de vida más bien
+complejo. El cuerpo de la definición de una instrucción de marcado es
+responsable de la conversión de los argumentos de la instrucción de
+marcado en una expresión de sello que se devuelve. Muy a menudo esto
+se lleva a cabo llamando a la función @code{interpret-markup} sobre
+una expresión de marcado, pasándole los argumentos @var{layout} y
+@var{props}. Por lo general, estos argumentos se conocen solamente en
+una fase muy tardía de la composición tipográfica. Las expresiones de
+marcado ya tienen sus componentes ensamblados dentro de expresiones de
+marcado cuando se expanden las instrucciones @code{\markup} (dentro de
+una expresión de LilyPond) o la macro @code{markup} (dentro de
+Scheme). La evaluación y la comprobación de tipos de los argumentos
+de la instrucción de marcado tiene lugar en el momento en que se
+interpretan @code{\markup} o @code{markup}.
+
+Pero la conversión real de expresiones de marcado en expresiones de
+sello mediante la ejecución de los cuerpos de función de marcado solo
+tienen lugar cuando se llama a @code{interpret-markup} sobre una
+expresión de marcado.
+
@node Acerca de las propiedades
@unnumberedsubsubsec Acerca de las propiedades
@translationof On properties
\override #'(box-padding . 0.6) \box @{ #text @}#@}))
@end lisp
-or, equivalently
+o, de forma equivalente,
@lisp
#(define-markup-command (double-box layout props text) (markup?)
@subsection Definición de nuevas instrucciones de lista de marcado
@translationof New markup list command definition
+@funindex define-markup-list-command
+@funindex interpret-markup-list
+
Las instrucciones de listas de marcado se definen con el macro de
Scheme @code{define-markup-list-command}, que es similar al macro
@code{define-markup-command} descrito en @ref{Definición de una
El procedimiento siempre toma un argumento único, que es el grob (el
objeto gráfico).
+Dicho procedimiento puede acceder al valor usual de la propiedad,
+llamando en primer lugar a la función que es el @q{callback} usual
+para esa propiedad, y que puede verse en el manual de referencia
+interna o en el archivo 'define-grobs.scm':
+
+@example
+\relative c'' @{
+ \override Flag #'X-offset = #(lambda (flag)
+ (let ((default (ly:flag::calc-x-offset flag)))
+ (* default 4.0)))
+ c4. d8 a4. g8
+@}
+@end example
+
Si se deben llamar rutinas con varios argumentos, el grob actual se
puede insertar con una cerradura de grob. He aquí un ajuste
procedente de @code{AccidentalSuggestion},
@translationof Inline Scheme code
La principal desventaja de @code{\tweak} es su inflexibilidad
-sintáctica. Por ejemplo, lo siguiente produce un error de sintaxis.
+sintáctica. Por ejemplo, lo siguiente produce un error de sintaxis (o
+más bien: así lo hacía en algún momento del pasado):
@example
F = \tweak font-size #-3 -\flageolet
\override Tie.after-line-breaking =
#my-callback
c1 ~ \break
- c2 ~ c
+ c2 ~ 2
}
@end lilypond
projects / lilypond.git / blobdiff