]> git.donarmstrong.com Git - lilypond.git/blob - Documentation/extending/programming-interface.itely
861105029f5a64e5e896725105fd7ae05fd88b1c
[lilypond.git] / Documentation / extending / programming-interface.itely
1 @c -*- coding: utf-8; mode: texinfo; -*-
2
3 @ignore
4     Translation of GIT committish: FILL-IN-HEAD-COMMITTISH
5
6     When revising a translation, copy the HEAD committish of the
7     version that you are working on.  For details, see the Contributors'
8     Guide, node Updating translation committishes..
9 @end ignore
10
11 @c \version "2.19.24"
12
13 @node Interfaces for programmers
14 @chapter Interfaces for programmers
15
16 Advanced tweaks may be performed by using Scheme.  If you are
17 not familiar with Scheme, you may wish to read our
18 @ref{Scheme tutorial}.
19
20 @menu
21 * LilyPond code blocks::
22 * Scheme functions::
23 * Music functions::
24 * Event functions::
25 * Markup functions::
26 * Contexts for programmers::
27 * Callback functions::
28 * Difficult tweaks::
29 @end menu
30
31 @node LilyPond code blocks
32 @section LilyPond code blocks
33
34 @cindex LilyPond code blocks
35 @cindex code blocks, LilyPond
36 @funindex #@{ @dots{} #@}
37 @funindex $
38 @funindex #
39
40 Creating music expressions in Scheme can be tedious, as they are
41 heavily nested and the resulting Scheme code is large. For some
42 simple tasks this can be avoided by using LilyPond code blocks,
43 which enable common LilyPond syntax to be used within Scheme.
44
45 LilyPond code blocks look like
46
47 @example
48   #@{ @var{LilyPond code} #@}
49 @end example
50
51 Here is a trivial example:
52
53 @lilypond[verbatim,quote]
54 ritpp = #(define-event-function () ()
55   #{ ^"rit." \pp #}
56 )
57
58 { c'4 e'4\ritpp g'2 }
59 @end lilypond
60
61 LilyPond code blocks can be used anywhere where you can write Scheme
62 code.  The Scheme reader actually is changed for accommodating
63 LilyPond code blocks and can deal with embedded Scheme expressions
64 starting with @code{$} and@w{ }@code{#}.
65
66 The reader extracts the LilyPond code block and generates a runtime
67 call to the LilyPond parser to interpret the LilyPond code.
68 Scheme expressions embedded in the LilyPond code are evaluated in the
69 lexical environment of the LilyPond code block, so all local variables
70 and function parameters available at the point the LilyPond code block
71 is written may be accessed.  Variables defined in other Scheme modules,
72 like the modules containing @code{\header} and @code{\layout} blocks,
73 are not accessible as Scheme variables, i.e. prefixed
74 with@tie{}@code{#}, but they are accessible as LilyPond variables, i.e.
75 prefixed with@tie{}@code{\}.
76
77 All music generated inside the code block has its
78 @samp{origin} set to the current input location.
79
80 A LilyPond code block may contain anything that you can use on the
81 right side of an assignment.  In addition, an empty LilyPond block
82 corresponds to a void music expression, and a LilyPond block
83 containing multiple music events gets turned into a sequential music
84 expression.
85
86 @node Scheme functions
87 @section Scheme functions
88 @cindex Scheme functions (LilyPond syntax)
89
90 @emph{Scheme functions} are Scheme procedures that can create Scheme
91 expressions from input written in LilyPond syntax.  They can be called
92 in pretty much all places where using @code{#} for specifying a value in
93 Scheme syntax is allowed.  While Scheme has functions of its own, this
94 chapter is concerned with @emph{syntactic} functions, functions that
95 receive arguments specified in LilyPond syntax.
96
97 @menu
98 * Scheme function definitions::
99 * Scheme function usage::
100 * Void scheme functions::
101 @end menu
102
103 @node Scheme function definitions
104 @subsection Scheme function definitions
105 @funindex define-scheme-function
106
107 The general form for defining scheme functions is:
108
109 @example
110 function =
111 #(define-scheme-function
112      (@var{arg1} @var{arg2} @dots{})
113      (@var{type1?} @var{type2?} @dots{})
114    @var{body})
115 @end example
116
117 @noindent
118 where
119
120 @multitable @columnfractions .33 .66
121 @item @code{@var{argN}}
122 @tab @var{n}th argument
123
124 @item @code{@var{typeN?}}
125 @tab a Scheme @emph{type predicate} for which @code{@var{argN}}
126 must return @code{#t}.  There is also a special form
127 @code{(@emph{predicate?} @emph{default})} for specifying optional
128 arguments.  If the actual argument is missing when the function is being
129 called, the default value is substituted instead.  Default values are
130 evaluated at definition time (including LilyPond code blocks!), so if
131 you need a default calculated at runtime, instead write a special value
132 you can easily recognize.  If you write the predicate in parentheses but
133 don't follow it with a default value, @code{#f} is used as the default.
134 Default values are not verified with @emph{predicate?} at either
135 definition or run time: it is your responsibility to deal with the
136 values you specify.  Default values that happen to be music expressions
137 are copied while setting @code{origin} to the current input location.
138
139 @item @code{@var{body}}
140 @tab A sequence of Scheme forms evaluated in order, the last one being
141 used as the return value of the scheme function.  It may contain
142 LilyPond code blocks enclosed in hashed braces
143 (@tie{}@w{@code{#@{@dots{}#@}}}@tie{}), like described in
144 @ref{LilyPond code blocks}.  Within LilyPond code blocks, use @code{#}
145 to reference function arguments (eg., @samp{#arg1}) or to start an
146 inline Scheme expression containing function arguments (eg.,
147 @w{@samp{#(cons arg1 arg2)}}).  Where normal Scheme expressions using
148 @code{#} don't do the trick, you might need to revert to immediate
149 Scheme expressions using @code{$}, for example as @samp{$music}.
150
151 If your function returns a music expression, it is given a useful value
152 of @code{origin}.
153 @end multitable
154
155 @noindent
156 Suitability of arguments for the predicates is determined by
157 actually calling the predicate after LilyPond has already converted them
158 into a Scheme expression.  As a consequence, the argument can be
159 specified in Scheme syntax if desired (introduced with @code{#} or as
160 the result of calling a scheme function), but LilyPond will also convert
161 a number of LilyPond constructs into Scheme before actually checking the
162 predicate on them.  Currently, those include music, postevents, simple
163 strings (with or without quotes), numbers, full markups and markup
164 lists, score, book, bookpart, context definition and output definition
165 blocks.
166
167 Some
168 ambiguities LilyPond sorts out by checking with predicate
169 functions: is @samp{-3} a fingering postevent or a negative number?  Is
170 @code{"a" 4} in lyric mode a string followed by a number, or a lyric
171 event of duration @code{4}?  LilyPond tries the argument
172 predicate on successive interpretations until success, with an
173 order designed to minimize inconsistent interpretations and
174 lookahead.
175
176 For example, a predicate accepting both music expressions and
177 pitches will consider @code{c''} to be a pitch rather than a music
178 expression.  Immediately following durations or postevents will
179 change that interpretation.  It's best to avoid overly
180 permissive predicates like @code{scheme?} when the application
181 rather calls for more specific argument types.
182
183 For a list of available predefined type predicates, see
184 @ruser{Predefined type predicates}.
185
186 @seealso
187
188 Notation Reference:
189 @ruser{Predefined type predicates}.
190
191 Installed Files:
192 @file{lily/music-scheme.cc},
193 @file{scm/c++.scm},
194 @file{scm/lily.scm}.
195
196 @node Scheme function usage
197 @subsection Scheme function usage
198
199 Scheme functions can be called pretty much anywhere where a Scheme
200 expression starting with @code{#} can be written.  You call a
201 scheme function from LilyPond by writing its name preceded by
202 @code{\}, followed by its arguments.  Once an optional argument
203 predicate does not match an argument, LilyPond skips this and all
204 following optional arguments, replacing them with their specified
205 default, and @q{backs up} the argument that did not match to the
206 place of the next mandatory argument.  Since the backed up
207 argument needs to go somewhere, optional arguments are not
208 actually considered optional unless followed by a mandatory
209 argument.
210
211 There is one exception: if you write @code{\default} in the place of an
212 optional argument, this and all following optional arguments are skipped
213 and replaced by their default.  This works even when no mandatory
214 argument follows since @code{\default} does not need to get backed up.
215 The @code{mark} and @code{key} commands make use of that trick to
216 provide their default behavior when just followed by @code{\default}.
217
218 Apart from places where a Scheme value is required, there are a few
219 places where @code{#} expressions are currently accepted and evaluated
220 for their side effects but otherwise ignored.  Mostly those are the
221 places where an assignment would be acceptable as well.
222
223 Since it is a bad idea to return values that can be misinterpreted in
224 some context, you should use normal scheme functions only for those
225 cases where you always return a useful value, and use void scheme
226 functions (@pxref{Void scheme functions}) otherwise.
227
228 For convenience, scheme functions may also be called directly from
229 Scheme bypassing the LilyPond parser.  Their name can be used like
230 the name of an ordinary function.  Typechecking of the arguments
231 and skipping optional arguments will happen in the same manner as
232 when called from within LilyPond, with the Scheme value
233 @code{*unspecified*} taking the role of the @code{\default}
234 reserved word for explicitly skipping optional arguments.
235
236 @node Void scheme functions
237 @subsection Void scheme functions
238 @funindex define-void-function
239 @funindex \void
240
241 Sometimes a procedure is executed in order to perform an action rather
242 than return a value.  Some programming languages (like C and Scheme) use
243 functions for either concept and just discard the returned value
244 (usually by allowing any expression to act as statement, ignoring the
245 result).  This is clever but error-prone: most C compilers nowadays
246 offer warnings for various non-``void'' expressions being discarded.
247 For many functions executing an action, the Scheme standards declare the
248 return value to be unspecified.  LilyPond's Scheme interpreter Guile has
249 a unique value @code{*unspecified*} that it usually (such when using
250 @code{set!} directly on a variable) but unfortunately not consistently
251 returns in such cases.
252
253 Defining a LilyPond function with @code{define-void-function} makes
254 sure that this special value (the only value satisfying the predicate
255 @code{void?}) will be returned.
256
257 @example
258 noPointAndClick =
259 #(define-void-function
260      ()
261      ()
262    (ly:set-option 'point-and-click #f))
263 @dots{}
264 \noPointAndClick   % disable point and click
265 @end example
266
267 If you want to evaluate an expression only for its side-effect and
268 don't want any value it may return interpreted, you can do so by
269 prefixing it with @code{\void}:
270
271 @example
272 \void #(hashq-set! some-table some-key some-value)
273 @end example
274
275 That way, you can be sure that LilyPond will not assign meaning to the
276 returned value regardless of where it encounters it.  This will also
277 work for music functions such as @code{\displayMusic}.
278
279 @node Music functions
280 @section Music functions
281
282 @cindex music functions
283
284 @emph{Music functions} are Scheme procedures that can create music
285 expressions automatically, and can be used to greatly simplify the
286 input file.
287
288 @menu
289 * Music function definitions::
290 * Music function usage::
291 * Simple substitution functions::
292 * Intermediate substitution functions::
293 * Mathematics in functions::
294 * Functions without arguments::
295 * Void music functions::
296 @end menu
297
298
299 @node Music function definitions
300 @subsection Music function definitions
301 @cindex defining music functions
302 @funindex define-music-function
303
304 The general form for defining music functions is:
305
306 @example
307 function =
308 #(define-music-function
309      (@var{arg1} @var{arg2} @dots{})
310      (@var{type1?} @var{type2?} @dots{})
311    @var{body})
312 @end example
313
314 @noindent
315 quite in analogy to @ref{Scheme function definitions}.  More often than
316 not, @var{body} will be a @ref{LilyPond code blocks, LilyPond code block}.
317
318 For a list of available type predicates, see
319 @ruser{Predefined type predicates}.
320
321 @seealso
322
323 Notation Reference:
324 @ruser{Predefined type predicates}.
325
326 Installed Files:
327 @file{lily/music-scheme.cc},
328 @file{scm/c++.scm},
329 @file{scm/lily.scm}.
330
331
332 @node Music function usage
333 @subsection Music function usage
334 A @q{music function} has to return an expression matching the predicate
335 @code{ly:music?}.  This makes music function calls suitable as arguments
336 of type @code{ly:music?} for another music function call.
337
338 When using a music function call in other contexts, the context may
339 cause further semantic restrictions.
340
341 @itemize
342 @item
343 At the top level in a music expression a post-event is not accepted.
344
345 @item
346 When a music function (as opposed to an event function) returns an
347 expression of type post-event, LilyPond requires one of the named
348 direction indicators (@code{-}, @code{^}, @w{and @code{_}})) in order to
349 properly integrate the post-event produced by the music function call
350 into the surrounding expression.
351
352 @item
353 As a chord constituent.  The returned expression must be of a
354 @code{rhythmic-event} type, most likely a @code{NoteEvent}.
355 @end itemize
356
357 @noindent
358 @q{Polymorphic} functions, like @code{\tweak}, can be applied to
359 post-events, chord constituent and top level music expressions.
360
361 @node Simple substitution functions
362 @subsection Simple substitution functions
363
364 Simple substitution functions are music functions whose output
365 music expression is written in LilyPond format and contains
366 function arguments in the output expression.  They are described
367 in @ruser{Substitution function examples}.
368
369
370 @node Intermediate substitution functions
371 @subsection Intermediate substitution functions
372
373 Intermediate substitution functions involve a mix of Scheme code
374 and LilyPond code in the music expression to be returned.
375
376 Some @code{\override} commands require an argument consisting of
377 a pair of numbers (called a @emph{cons cell} in Scheme).
378
379 The pair can be directly passed into the music function,
380 using a @code{pair?} variable:
381
382 @example
383 manualBeam =
384 #(define-music-function
385      (beg-end)
386      (pair?)
387    #@{
388      \once \override Beam.positions = #beg-end
389    #@})
390
391 \relative c' @{
392   \manualBeam #'(3 . 6) c8 d e f
393 @}
394 @end example
395
396 Alternatively, the numbers making up the pair can be
397 passed as separate arguments, and the Scheme code
398 used to create the pair can be included in the
399 music expression:
400
401 @lilypond[quote,verbatim,ragged-right]
402 manualBeam =
403 #(define-music-function
404      (beg end)
405      (number? number?)
406    #{
407      \once \override Beam.positions = #(cons beg end)
408    #})
409
410 \relative c' {
411   \manualBeam #3 #6 c8 d e f
412 }
413 @end lilypond
414
415 @funindex \temporary
416 @cindex temporary overrides
417 @cindex overrides, temporary
418 @cindex properties, popping previous value
419
420 Properties are maintained conceptually using one stack per property
421 per grob per context.  Music functions may need to override one or
422 several properties for the duration of the function, restoring them
423 to their previous value before exiting.  However, normal overrides
424 pop and discard the top of the current property stack before
425 pushing to it, so the previous value of the property is lost when it
426 is overridden.  When the previous value must be preserved, prefix the
427 @code{\override} command with @code{\temporary}, like this:
428
429 @example
430 \temporary \override @dots{}
431 @end example
432
433 The use of @code{\temporary} causes the (usually set) @code{pop-first}
434 property in the override to be cleared, so the previous value is not
435 popped off the property stack before pushing the new value onto it.
436 When a subsequent @code{\revert} pops off the temporarily overriden
437 value, the previous value will re-emerge.
438
439 In other words, calling @code{\temporary \override} and @code{\revert}
440 in succession on the same property will have a net effect of zero.
441 Similarly, pairing @code{\temporary} and @code{\undo} on the same
442 music containing overrides will have a net effect of zero.
443
444 Here is an example of a music function which makes use of this.
445 The use of @code{\temporary} ensures the values of the
446 @code{cross-staff} and @code{style} properties are restored on exit
447 to whatever values they had when the @code{crossStaff} function was
448 called.  Without @code{\temporary} the default values would have been
449 set on exit.
450
451 @example
452 crossStaff =
453 #(define-music-function (notes) (ly:music?)
454   (_i "Create cross-staff stems")
455   #@{
456   \temporary \override Stem.cross-staff = #cross-staff-connect
457   \temporary \override Flag.style = #'no-flag
458   #notes
459   \revert Stem.cross-staff
460   \revert Flag.style
461 #@})
462 @end example
463
464
465 @node Mathematics in functions
466 @subsection Mathematics in functions
467
468 Music functions can involve Scheme programming in
469 addition to simple substitution,
470
471 @lilypond[quote,verbatim,ragged-right]
472 AltOn =
473 #(define-music-function
474      (mag)
475      (number?)
476    #{
477      \override Stem.length = #(* 7.0 mag)
478      \override NoteHead.font-size =
479        #(inexact->exact (* (/ 6.0 (log 2.0)) (log mag)))
480    #})
481
482 AltOff = {
483   \revert Stem.length
484   \revert NoteHead.font-size
485 }
486
487 \relative {
488   c'2 \AltOn #0.5 c4 c
489   \AltOn #1.5 c c \AltOff c2
490 }
491 @end lilypond
492
493 @noindent
494 This example may be rewritten to pass in music expressions,
495
496 @lilypond[quote,verbatim,ragged-right]
497 withAlt =
498 #(define-music-function
499      (mag music)
500      (number? ly:music?)
501    #{
502      \override Stem.length = #(* 7.0 mag)
503      \override NoteHead.font-size =
504        #(inexact->exact (* (/ 6.0 (log 2.0)) (log mag)))
505      #music
506      \revert Stem.length
507      \revert NoteHead.font-size
508    #})
509
510 \relative {
511   c'2 \withAlt #0.5 { c4 c }
512   \withAlt #1.5 { c c } c2
513 }
514 @end lilypond
515
516
517 @node Functions without arguments
518 @subsection Functions without arguments
519
520 In most cases a function without arguments should be written
521 with a variable,
522
523 @example
524 dolce = \markup@{ \italic \bold dolce @}
525 @end example
526
527 However, in rare cases it may be useful to create a music function
528 without arguments,
529
530 @example
531 displayBarNum =
532 #(define-music-function
533      ()
534      ()
535    (if (eq? #t (ly:get-option 'display-bar-numbers))
536        #@{ \once \override Score.BarNumber.break-visibility = ##f #@}
537        #@{#@}))
538 @end example
539
540 To actually display bar numbers where this function is called,
541 invoke @command{lilypond} with
542
543 @example
544 lilypond -d display-bar-numbers FILENAME.ly
545 @end example
546
547
548 @node Void music functions
549 @subsection Void music functions
550
551 A music function must return a music expression.  If you want to
552 execute a function only for its side effect, you should use
553 @code{define-void-function}.  But there may be cases where you
554 sometimes want to produce a music expression, and sometimes not (like
555 in the previous example).  Returning a @code{void} music expression
556 via @code{#@{ #@}} will achieve that.
557
558 @node Event functions
559 @section Event functions
560 @funindex define-event-function
561 @cindex event functions
562
563 To use a music function in the place of an event, you need to write a
564 direction indicator before it.  But sometimes, this does not quite match
565 the syntax of constructs you want to replace.  For example, if you want
566 to write dynamics commands, those are usually attached without direction
567 indicator, like @code{c'\pp}.  Here is a way to write arbitrary
568 dynamics:
569 @lilypond[quote,verbatim,ragged-right]
570 dyn=#(define-event-function (arg) (markup?)
571          (make-dynamic-script arg))
572 \relative { c'\dyn pfsss }
573 @end lilypond
574 You could do the same using a music function, but then you always would
575 have to write a direction indicator before calling it, like
576 @code{@w{c-\dyn pfsss}}.
577
578
579 @node Markup functions
580 @section Markup functions
581
582 Markups are implemented as special Scheme functions which produce a
583 @code{Stencil} object given a number of arguments.
584
585 @menu
586 * Markup construction in Scheme::
587 * How markups work internally::
588 * New markup command definition::
589 * New markup list command definition::
590 @end menu
591
592
593 @node Markup construction in Scheme
594 @subsection Markup construction in Scheme
595
596 @cindex defining markup commands
597 @funindex \displayScheme
598
599 Markup expressions are internally represented in Scheme using the
600 @code{markup} macro:
601
602 @example
603 (markup @var{expr})
604 @end example
605
606 To see a markup expression in its Scheme form, use the
607 @code{\displayScheme} command:
608
609 @example
610 \displayScheme
611 \markup @{
612   \column @{
613     \line @{ \bold \italic "hello" \raise #0.4 "world" @}
614     \larger \line @{ foo bar baz @}
615   @}
616 @}
617 @end example
618
619 @noindent
620 Compiling the code above will send the following to the display
621 console:
622
623 @example
624 (markup
625   #:line
626   (#:column
627    (#:line
628     (#:bold (#:italic "hello") #:raise 0.4 "world")
629     #:larger
630     (#:line
631      (#:simple "foo" #:simple "bar" #:simple "baz")))))
632 @end example
633
634 To prevent the markup from printing on the page, use
635 @w{@samp{\void \displayScheme @var{markup}}}.  Also, as with the
636 @code{\displayMusic} command, the output of @code{\displayScheme}
637 can be saved to an external file.  See
638 @ref{Displaying music expressions}.
639
640 @noindent
641 This example demonstrates the main translation rules between regular
642 LilyPond markup syntax and Scheme markup syntax.  Using @code{#@{
643 @dots{} #@}} for entering in LilyPond syntax will often be most
644 convenient, but we explain how to use the @code{markup} macro to get a
645 Scheme-only solution.
646
647 @quotation
648 @multitable @columnfractions .3 .3
649 @item @b{LilyPond} @tab @b{Scheme}
650 @item @code{\markup markup1} @tab @code{(markup markup1)}
651 @item @code{\markup @{ markup1 markup2 @dots{} @}} @tab
652         @code{(markup markup1 markup2 @dots{} )}
653 @item @code{\markup-command} @tab @code{#:markup-command}
654 @item @code{\variable} @tab @code{variable}
655 @item @code{\center-column @{ @dots{} @}} @tab
656         @code{#:center-column ( @dots{} )}
657 @item @code{string} @tab @code{"string"}
658 @item @code{#scheme-arg} @tab @code{scheme-arg}
659 @end multitable
660 @end quotation
661
662 The whole Scheme language is accessible inside the
663 @code{markup} macro.  For example, You may use function calls inside
664 @code{markup} in order to manipulate character strings.  This is
665 useful when defining new markup commands (see
666 @ref{New markup command definition}).
667
668
669 @knownissues
670
671 The markup-list argument of commands such as @code{#:line},
672 @code{#:center}, and @code{#:column} cannot be a variable or
673 the result of a function call.
674
675 @lisp
676 (markup #:line (function-that-returns-markups))
677 @end lisp
678
679 @noindent
680 is invalid.  One should use the @code{make-line-markup},
681 @code{make-center-markup}, or @code{make-column-markup} functions
682 instead,
683
684 @lisp
685 (markup (make-line-markup (function-that-returns-markups)))
686 @end lisp
687
688
689 @node How markups work internally
690 @subsection How markups work internally
691
692 In a markup like
693
694 @example
695 \raise #0.5 "text example"
696 @end example
697
698 @noindent
699 @code{\raise} is actually represented by the @code{raise-markup}
700 function.  The markup expression is stored as
701
702 @example
703 (list raise-markup 0.5 (list simple-markup "text example"))
704 @end example
705
706 When the markup is converted to printable objects (Stencils), the
707 @code{raise-markup} function is called as
708
709 @example
710 (apply raise-markup
711        @var{\layout object}
712        @var{list of property alists}
713        0.5
714        @var{the "text example" markup})
715 @end example
716
717 The @code{raise-markup} function first creates the stencil for the
718 @code{text example} string, and then it raises that Stencil by 0.5
719 staff space.  This is a rather simple example; more complex examples
720 are in the rest
721 of this section, and in @file{scm/define-markup-commands.scm}.
722
723
724 @node New markup command definition
725 @subsection New markup command definition
726
727 This section discusses the definition of new markup commands.
728
729 @menu
730 * Markup command definition syntax::
731 * On properties::
732 * A complete example::
733 * Adapting builtin commands::
734 @end menu
735
736 @node Markup command definition syntax
737 @unnumberedsubsubsec Markup command definition syntax
738
739 New markup commands can be defined using the
740 @code{define-markup-command} Scheme macro, at top-level.
741
742 @lisp
743 (define-markup-command (@var{command-name} @var{layout} @var{props} @var{arg1} @var{arg2} @dots{})
744     (@var{arg1-type?} @var{arg2-type?} @dots{})
745     [ #:properties ((@var{property1} @var{default-value1})
746                     @dots{}) ]
747   @dots{}command body@dots{})
748 @end lisp
749
750 The arguments are
751
752 @table @code
753 @item @var{command-name}
754 the markup command name
755 @item layout
756 the @q{layout} definition.
757 @item props
758 a list of associative lists, containing all active properties.
759 @item @var{argi}
760 @var{i}th command argument
761 @item @var{argi-type?}
762 a type predicate for the i@var{th} argument
763 @end table
764
765 If the command uses properties from the @code{props} arguments,
766 the @code{#:properties} keyword can be used to specify which
767 properties are used along with their default values.
768
769 Arguments are distinguished according to their type:
770 @itemize
771 @item a markup, corresponding to type predicate @code{markup?};
772 @item a list of markups, corresponding to type predicate
773 @code{markup-list?};
774 @item any other scheme object, corresponding to type predicates such as
775 @code{list?}, @code{number?}, @code{boolean?}, etc.
776 @end itemize
777
778 There is no limitation on the order of arguments (after the
779 standard @code{layout} and @code{props} arguments).  However,
780 markup functions taking a markup as their last argument are
781 somewhat special as you can apply them to a markup list, and the
782 result is a markup list where the markup function (with the
783 specified leading arguments) has been applied to every element of
784 the original markup list.
785
786 Since replicating the leading arguments for applying a markup
787 function to a markup list is cheap mostly for Scheme arguments,
788 you avoid performance pitfalls by just using Scheme arguments for
789 the leading arguments of markup functions that take a markup as
790 their last argument.
791
792 @funindex \markup
793 @cindex markup macro
794 @funindex interpret-markup
795 Markup commands have a rather complex life cycle.  The body of a
796 markup command definition is responsible for converting the
797 arguments of the markup command into a stencil expression which is
798 returned.  Quite often this is accomplished by calling the
799 @code{interpret-markup} function on a markup expression, passing
800 the @var{layout} and @var{props} arguments on to it.  Those
801 arguments are usually only known at a very late stage in
802 typesetting.  Markup expressions have their components assembled
803 into markup expressions already when @code{\markup} in a LilyPond
804 expression or the @code{markup} macro in Scheme is expanded.  The
805 evaluation and typechecking of markup command arguments happens at
806 the time @code{\markup}/@code{markup} are interpreted.
807
808 But the actual conversion of markup expressions into stencil
809 expressions by executing the markup function bodies only happens
810 when @code{interpret-markup} is called on a markup expression.
811
812 @node On properties
813 @unnumberedsubsubsec On properties
814
815 The @code{layout} and @code{props} arguments of markup commands bring a
816 context for the markup interpretation: font size, line width, etc.
817
818 The @code{layout} argument allows access to properties defined in
819 @code{paper} blocks, using the @code{ly:output-def-lookup} function.
820 For instance, the line width (the same as the one used in scores) is
821 read using:
822
823 @example
824 (ly:output-def-lookup layout 'line-width)
825 @end example
826
827 The @code{props} argument makes some properties accessible to markup
828 commands.  For instance, when a book title markup is interpreted, all
829 the variables defined in the @code{\header} block are automatically
830 added to @code{props}, so that the book title markup can access the book
831 title, composer, etc.  It is also a way to configure the behaviour of a
832 markup command: for example, when a command uses font size during
833 processing, the font size is read from @code{props} rather than having a
834 @code{font-size} argument.  The caller of a markup command may change
835 the value of the font size property in order to change the behaviour.
836 Use the @code{#:properties} keyword of @code{define-markup-command} to
837 specify which properties shall be read from the @code{props} arguments.
838
839 The example in next section illustrates how to access and override
840 properties in a markup command.
841
842 @node A complete example
843 @unnumberedsubsubsec A complete example
844
845 The following example defines a markup command to draw a double box
846 around a piece of text.
847
848 Firstly, we need to build an approximative result using markups.
849 Consulting the @ruser{Text markup commands} shows us the @code{\box}
850 command is useful:
851
852 @lilypond[quote,verbatim,ragged-right]
853 \markup \box \box HELLO
854 @end lilypond
855
856 Now, we consider that more padding between the text and the boxes is
857 preferable.  According to the @code{\box} documentation, this command
858 uses a @code{box-padding} property, which defaults to 0.2.  The
859 documentation also mentions how to override it:
860
861 @lilypond[quote,verbatim,ragged-right]
862 \markup \box \override #'(box-padding . 0.6) \box A
863 @end lilypond
864
865 Then, the padding between the two boxes is considered too small, so we
866 override it too:
867
868 @lilypond[quote,verbatim,ragged-right]
869 \markup \override #'(box-padding . 0.4) \box
870      \override #'(box-padding . 0.6) \box A
871 @end lilypond
872
873 Repeating this lengthy markup would be painful.  This is where a markup
874 command is needed.  Thus, we write a @code{double-box} markup command,
875 taking one argument (the text).  This draws the two boxes, with some
876 padding.
877
878 @lisp
879 #(define-markup-command (double-box layout props text) (markup?)
880   "Draw a double box around text."
881   (interpret-markup layout props
882     #@{\markup \override #'(box-padding . 0.4) \box
883             \override #'(box-padding . 0.6) \box @{ #text @}#@}))
884 @end lisp
885
886 or, equivalently
887
888 @lisp
889 #(define-markup-command (double-box layout props text) (markup?)
890   "Draw a double box around text."
891   (interpret-markup layout props
892     (markup #:override '(box-padding . 0.4) #:box
893             #:override '(box-padding . 0.6) #:box text)))
894 @end lisp
895
896 @code{text} is the name of the command argument, and @code{markup?} its
897 type: it identifies it as a markup.  The @code{interpret-markup}
898 function is used in most of markup commands: it builds a stencil, using
899 @code{layout}, @code{props}, and a markup.  In the second case, this
900 markup is built using the @code{markup} scheme macro, see @ref{Markup
901 construction in Scheme}.  The transformation from @code{\markup}
902 expression to scheme markup expression is straight-forward.
903
904 The new command can be used as follow:
905
906 @example
907 \markup \double-box A
908 @end example
909
910 It would be nice to make the @code{double-box} command customizable:
911 here, the @code{box-padding} values are hard coded, and cannot be
912 changed by the user.  Also, it would be better to distinguish the
913 padding between the two boxes, from the padding between the inner box
914 and the text.  So we will introduce a new property,
915 @code{inter-box-padding}, for the padding between the two boxes.  The
916 @code{box-padding} will be used for the inner padding.  The new code is
917 now as follows:
918
919 @lisp
920 #(define-markup-command (double-box layout props text) (markup?)
921   #:properties ((inter-box-padding 0.4)
922                 (box-padding 0.6))
923   "Draw a double box around text."
924   (interpret-markup layout props
925     #@{\markup \override #`(box-padding . ,inter-box-padding) \box
926                \override #`(box-padding . ,box-padding) \box
927                @{ #text @} #@}))
928 @end lisp
929
930 Again, the equivalent version using the markup macro would be:
931
932 @lisp
933 #(define-markup-command (double-box layout props text) (markup?)
934   #:properties ((inter-box-padding 0.4)
935                 (box-padding 0.6))
936   "Draw a double box around text."
937   (interpret-markup layout props
938     (markup #:override `(box-padding . ,inter-box-padding) #:box
939             #:override `(box-padding . ,box-padding) #:box text)))
940 @end lisp
941
942 Here, the @code{#:properties} keyword is used so that the
943 @code{inter-box-padding} and @code{box-padding} properties are read from
944 the @code{props} argument, and default values are given to them if the
945 properties are not defined.
946
947 Then, these values are used to override the @code{box-padding}
948 properties used by the two @code{\box} commands.  Note the backquote and
949 the comma in the @code{\override} argument: they allow you to introduce
950 a variable value into a literal expression.
951
952 Now, the command can be used in a markup, and the boxes padding be
953 customized:
954
955 @lilypond[quote,verbatim,ragged-right]
956 #(define-markup-command (double-box layout props text) (markup?)
957   #:properties ((inter-box-padding 0.4)
958                 (box-padding 0.6))
959   "Draw a double box around text."
960   (interpret-markup layout props
961     #{\markup \override #`(box-padding . ,inter-box-padding) \box
962               \override #`(box-padding . ,box-padding) \box
963               { #text } #}))
964
965 \markup \double-box A
966 \markup \override #'(inter-box-padding . 0.8) \double-box A
967 \markup \override #'(box-padding . 1.0) \double-box A
968 @end lilypond
969
970 @node Adapting builtin commands
971 @unnumberedsubsubsec Adapting builtin commands
972
973 A good way to start writing a new markup command, is to take example on
974 a builtin one.  Most of the markup commands provided with LilyPond can be
975 found in file @file{scm/define-markup-commands.scm}.
976
977 For instance, we would like to adapt the @code{\draw-line} command, to
978 draw a double line instead.  The @code{\draw-line} command is defined as
979 follow (documentation stripped):
980
981 @lisp
982 (define-markup-command (draw-line layout props dest)
983   (number-pair?)
984   #:category graphic
985   #:properties ((thickness 1))
986   "@dots{}documentation@dots{}"
987   (let ((th (* (ly:output-def-lookup layout 'line-thickness)
988                thickness))
989         (x (car dest))
990         (y (cdr dest)))
991     (make-line-stencil th 0 0 x y)))
992 @end lisp
993
994 To define a new command based on an existing one, copy the definition,
995 and change the command name.  The @code{#:category} keyword can be
996 safely removed, as it is only used for generating LilyPond
997 documentation, and is of no use for user-defined markup commands.
998
999 @lisp
1000 (define-markup-command (draw-double-line layout props dest)
1001   (number-pair?)
1002   #:properties ((thickness 1))
1003   "@dots{}documentation@dots{}"
1004   (let ((th (* (ly:output-def-lookup layout 'line-thickness)
1005                thickness))
1006         (x (car dest))
1007         (y (cdr dest)))
1008     (make-line-stencil th 0 0 x y)))
1009 @end lisp
1010
1011 Then, a property for setting the gap between two lines is added, called
1012 @code{line-gap}, defaulting e.g. to 0.6:
1013
1014 @lisp
1015 (define-markup-command (draw-double-line layout props dest)
1016   (number-pair?)
1017   #:properties ((thickness 1)
1018                 (line-gap 0.6))
1019   "@dots{}documentation@dots{}"
1020   @dots{}
1021 @end lisp
1022
1023 Finally, the code for drawing two lines is added.  Two calls to
1024 @code{make-line-stencil} are used to draw the lines, and the resulting
1025 stencils are combined using @code{ly:stencil-add}:
1026
1027 @lilypond[quote,verbatim,ragged-right]
1028 #(define-markup-command (my-draw-line layout props dest)
1029   (number-pair?)
1030   #:properties ((thickness 1)
1031                 (line-gap 0.6))
1032   "..documentation.."
1033   (let* ((th (* (ly:output-def-lookup layout 'line-thickness)
1034                 thickness))
1035          (dx (car dest))
1036          (dy (cdr dest))
1037          (w (/ line-gap 2.0))
1038          (x (cond ((= dx 0) w)
1039                   ((= dy 0) 0)
1040                   (else (/ w (sqrt (+ 1 (* (/ dx dy) (/ dx dy))))))))
1041          (y (* (if (< (* dx dy) 0) 1 -1)
1042                (cond ((= dy 0) w)
1043                      ((= dx 0) 0)
1044                      (else (/ w (sqrt (+ 1 (* (/ dy dx) (/ dy dx))))))))))
1045      (ly:stencil-add (make-line-stencil th x y (+ dx x) (+ dy y))
1046                      (make-line-stencil th (- x) (- y) (- dx x) (- dy y)))))
1047
1048 \markup \my-draw-line #'(4 . 3)
1049 \markup \override #'(line-gap . 1.2) \my-draw-line #'(4 . 3)
1050 @end lilypond
1051
1052
1053 @node New markup list command definition
1054 @subsection New markup list command definition
1055 @funindex define-markup-list-command
1056 @funindex interpret-markup-list
1057 Markup list commands are defined with the
1058 @code{define-markup-list-command} Scheme macro, which is similar to the
1059 @code{define-markup-command} macro described in
1060 @ref{New markup command definition}, except that where the latter returns
1061 a single stencil, the former returns a list of stencils.
1062
1063 In a similar vein, @code{interpret-markup-list} is used instead of
1064 @code{interpret-markup} for converting a markup list into a list
1065 of stencils.
1066
1067 In the following example, a @code{\paragraph} markup list command is
1068 defined, which returns a list of justified lines, the first one being
1069 indented.  The indent width is taken from the @code{props} argument.
1070
1071 @example
1072 #(define-markup-list-command (paragraph layout props args) (markup-list?)
1073    #:properties ((par-indent 2))
1074    (interpret-markup-list layout props
1075      #@{\markuplist \justified-lines @{ \hspace #par-indent #args @} #@}))
1076 @end example
1077
1078
1079 The version using just Scheme is more complex:
1080 @example
1081 #(define-markup-list-command (paragraph layout props args) (markup-list?)
1082    #:properties ((par-indent 2))
1083    (interpret-markup-list layout props
1084      (make-justified-lines-markup-list (cons (make-hspace-markup par-indent)
1085                                              args))))
1086 @end example
1087
1088 Besides the usual @code{layout} and @code{props} arguments, the
1089 @code{paragraph} markup list command takes a markup list argument, named
1090 @code{args}.  The predicate for markup lists is @code{markup-list?}.
1091
1092 First, the function gets the indent width, a property here named
1093 @code{par-indent}, from the property list @code{props}.  If the
1094 property is not found, the default value is @code{2}.  Then, a
1095 list of justified lines is made using the built-in markup list command
1096 @code{\justified-lines}, which is related to the
1097 @code{make-justified-lines-markup-list} function.  A
1098 horizontal space is added at the beginning using @code{\hspace} (or the
1099 @code{make-hspace-markup} function).  Finally, the markup list is
1100 interpreted using the @code{interpret-markup-list} function.
1101
1102 This new markup list command can be used as follows:
1103 @example
1104 \markuplist @{
1105   \paragraph @{
1106     The art of music typography is called \italic @{(plate) engraving.@}
1107     The term derives from the traditional process of music printing.
1108     Just a few decades ago, sheet music was made by cutting and stamping
1109     the music into a zinc or pewter plate in mirror image.
1110   @}
1111   \override-lines #'(par-indent . 4) \paragraph @{
1112     The plate would be inked, the depressions caused by the cutting
1113     and stamping would hold ink.  An image was formed by pressing paper
1114     to the plate.  The stamping and cutting was completely done by
1115     hand.
1116   @}
1117 @}
1118 @end example
1119
1120 @node Contexts for programmers
1121 @section Contexts for programmers
1122
1123 @menu
1124 * Context evaluation::
1125 * Running a function on all layout objects::
1126 @end menu
1127
1128 @node Context evaluation
1129 @subsection Context evaluation
1130
1131 @cindex calling code during interpreting
1132 @funindex \applyContext
1133 @funindex make-apply-context
1134 @funindex ly:context-property
1135 @funindex ly:context-set-property!
1136 @funindex ly:context-grob-definition
1137 @funindex ly:assoc-get
1138 @funindex ly:context-pushpop-property
1139
1140 Contexts can be modified during interpretation with Scheme code.
1141 In a LilyPond code block, the syntax for this is:
1142
1143 @example
1144 \applyContext @var{function}
1145 @end example
1146
1147 In Scheme code, the syntax is:
1148
1149 @example
1150 (make-apply-context @var{function})
1151 @end example
1152
1153 @code{@var{function}} should be a Scheme function that takes a
1154 single argument: the context in which the @code{\applyContext}
1155 command is being called.  The function can access as well as
1156 override/set grob properties and context properties.  Any actions
1157 taken by the function that depend on the state of the context are
1158 limited to the state of the context @emph{when the function is
1159 called}.  Also, changes effected by a call to @code{\applyContext}
1160 remain in effect until they are directly modified again, or
1161 reverted, even if the initial conditions that they depended on
1162 have changed.
1163
1164 The following scheme functions are useful when using
1165 @code{\applyContext}:
1166
1167 @table @code
1168 @item ly:context-property
1169 look up a context property value
1170
1171 @item ly:context-set-property!
1172 set a context property
1173
1174 @item ly:context-grob-definition
1175 @itemx ly:assoc-get
1176 look up a grob property value
1177
1178 @item ly:context-pushpop-property
1179 do a @code{\temporary@tie{}\override}
1180 or a @code{\revert} on a grob property
1181 @end table
1182
1183
1184 The following example looks up the current @code{fontSize} value, and
1185 then doubles it:
1186
1187 @lilypond[quote,verbatim]
1188 doubleFontSize =
1189 \applyContext
1190   #(lambda (context)
1191      (let ((fontSize (ly:context-property context 'fontSize)))
1192        (ly:context-set-property! context 'fontSize (+ fontSize 6))))
1193
1194 {
1195   \set fontSize = -3
1196   b'4
1197   \doubleFontSize
1198   b'
1199 }
1200 @end lilypond
1201
1202
1203 The following example looks up the current colors of the
1204 @code{NoteHead}, @code{Stem}, and @code{Beam} grobs, and then changes
1205 each to a less saturated shade.
1206
1207 @lilypond[quote,verbatim]
1208 desaturate =
1209 \applyContext
1210   #(lambda (context)
1211      (define (desaturate-grob grob)
1212        (let* ((grob-def (ly:context-grob-definition context grob))
1213               (color (ly:assoc-get 'color grob-def black))
1214               (new-color (map (lambda (x) (min 1 (/ (1+ x) 2))) color)))
1215          (ly:context-pushpop-property context grob 'color new-color)))
1216      (for-each desaturate-grob '(NoteHead Stem Beam)))
1217
1218 \relative {
1219   \time 3/4
1220   g'8[ g] \desaturate g[ g] \desaturate g[ g]
1221   \override NoteHead.color = #darkred
1222   \override Stem.color = #darkred
1223   \override Beam.color = #darkred
1224   g[ g] \desaturate g[ g] \desaturate g[ g]
1225 }
1226 @end lilypond
1227
1228
1229 This also could be implemented as a music function, in order to
1230 restrict the modifications to a single music block.  Notice how
1231 @code{ly:context-pushpop-property} is used both as a
1232 @code{\temporary@tie{}\override} and as a @code{\revert}:
1233
1234 @lilypond[quote,verbatim]
1235 desaturate =
1236 #(define-music-function
1237    (music) (ly:music?)
1238    #{
1239      \applyContext
1240      #(lambda (context)
1241         (define (desaturate-grob grob)
1242           (let* ((grob-def (ly:context-grob-definition context grob))
1243                  (color (ly:assoc-get 'color grob-def black))
1244                  (new-color (map (lambda (x) (min 1 (/ (1+ x) 2))) color)))
1245             (ly:context-pushpop-property context grob 'color new-color)))
1246         (for-each desaturate-grob '(NoteHead Stem Beam)))
1247      #music
1248      \applyContext
1249      #(lambda (context)
1250         (define (revert-color grob)
1251           (ly:context-pushpop-property context grob 'color))
1252         (for-each revert-color '(NoteHead Stem Beam)))
1253    #})
1254
1255 \relative {
1256   \override NoteHead.color = #darkblue
1257   \override Stem.color = #darkblue
1258   \override Beam.color = #darkblue
1259   g'8 a b c
1260   \desaturate { d c b a }
1261   g b d b g2
1262 }
1263 @end lilypond
1264
1265
1266 @node Running a function on all layout objects
1267 @subsection Running a function on all layout objects
1268
1269
1270 @cindex calling code on layout objects
1271 @funindex \applyOutput
1272
1273 The most versatile way of tuning an object is @code{\applyOutput} which
1274 works by inserting an event into the specified context
1275 (@rinternals{ApplyOutputEvent}).  Its syntax is either
1276 @example
1277 \applyOutput @var{Context} @var{proc}
1278 @end example
1279 or
1280 @example
1281 \applyOutput @var{Context}.@var{Grob} @var{proc}
1282 @end example
1283
1284 @noindent
1285 where @code{@var{proc}} is a Scheme function, taking three arguments.
1286
1287 When interpreted, the function @code{@var{proc}} is called for
1288 every layout object (with grob name @var{Grob} if specified) found
1289 in the context @code{@var{Context}} at the current time step, with
1290 the following arguments:
1291 @itemize
1292 @item the layout object itself,
1293 @item the context where the layout object was created, and
1294 @item the context where @code{\applyOutput} is processed.
1295 @end itemize
1296
1297
1298 In addition, the cause of the layout object, i.e., the music
1299 expression or object that was responsible for creating it, is in the
1300 object property @code{cause}.  For example, for a note head, this is a
1301 @rinternals{NoteHead} event, and for a stem object,
1302 this is a @rinternals{Stem} object.
1303
1304 Here is a function to use for @code{\applyOutput}; it blanks
1305 note-heads on the center-line and next to it:
1306
1307 @lilypond[quote,verbatim,ragged-right]
1308 #(define (blanker grob grob-origin context)
1309    (if (< (abs (ly:grob-property grob 'staff-position)) 2)
1310        (set! (ly:grob-property grob 'transparent) #t)))
1311
1312 \relative {
1313   a'4 e8 <<\applyOutput Voice.NoteHead #blanker a c d>> b2
1314 }
1315 @end lilypond
1316
1317 To have @var{function} interpreted at the @code{Score} or @code{Staff}
1318 level use these forms
1319
1320 @example
1321 \applyOutput Score@dots{}
1322 \applyOutput Staff@dots{}
1323 @end example
1324
1325
1326 @node Callback functions
1327 @section Callback functions
1328
1329 Properties (like @code{thickness}, @code{direction}, etc.) can be
1330 set at fixed values with @code{\override}, e.g.
1331
1332 @example
1333 \override Stem.thickness = #2.0
1334 @end example
1335
1336 Properties can also be set to a Scheme procedure,
1337
1338 @lilypond[fragment,verbatim,quote]
1339 \override Stem.thickness = #(lambda (grob)
1340     (if (= UP (ly:grob-property grob 'direction))
1341         2.0
1342         7.0))
1343 \relative { c'' b a g b a g b }
1344 @end lilypond
1345
1346 @noindent
1347 In this case, the procedure is executed as soon as the value of the
1348 property is requested during the formatting process.
1349
1350 Most of the typesetting engine is driven by such callbacks.
1351 Properties that typically use callbacks include
1352
1353 @table @code
1354 @item stencil
1355   The printing routine, that constructs a drawing for the symbol
1356 @item X-offset
1357   The routine that sets the horizontal position
1358 @item X-extent
1359   The routine that computes the width of an object
1360 @end table
1361
1362 The procedure always takes a single argument, being the grob.
1363
1364 That procedure may access the usual value of the property, by first
1365 calling the function that is the usual callback for that property, which
1366 can by found in the Internals Reference or the file 'define-grobs.scm':
1367
1368 @example
1369 \relative @{
1370   \override Flag.X-offset = #(lambda (flag)
1371     (let ((default (ly:flag::calc-x-offset flag)))
1372       (* default 4.0)))
1373   c''4. d8 a4. g8
1374 @}
1375 @end example
1376
1377 From within a callback, the easiest method for evaluating a markup is
1378 to use grob-interpret-markup.  For example:
1379
1380 @example
1381 my-callback = #(lambda (grob)
1382                  (grob-interpret-markup grob (markup "foo")))
1383 @end example
1384
1385 @ignore
1386
1387 @n ode Inline Scheme code
1388 @s ection Inline Scheme code
1389
1390 TODO: after this section had been written, LilyPond has improved
1391 to the point that finding a @emph{simple} example where one would
1392 @emph{have} to revert to Scheme has become rather hard.
1393
1394 Until this section gets a rewrite, let's pretend we don't know.
1395
1396 The main disadvantage of @code{\tweak} is its syntactical
1397 inflexibility.  For example, the following produces a syntax error
1398 (or rather, it did so at some point in the past).
1399
1400 @example
1401 F = \tweak font-size #-3 -\flageolet
1402
1403 \relative @{
1404   c''4^\F c4_\F
1405 @}
1406 @end example
1407
1408 @noindent
1409 Using Scheme, this problem can be avoided.  The route to the
1410 result is given in @ref{Adding articulation to notes (example)},
1411 especially how to use @code{\displayMusic} as a helping guide.
1412
1413 @example
1414 F = #(let ((m (make-music 'ArticulationEvent
1415                           'articulation-type "flageolet")))
1416        (set! (ly:music-property m 'tweaks)
1417              (acons 'font-size -3
1418                     (ly:music-property m 'tweaks)))
1419        m)
1420
1421 \relative @{
1422   c''4^\F c4_\F
1423 @}
1424 @end example
1425
1426 @noindent
1427 Here, the @code{tweaks} properties of the flageolet object
1428 @code{m} (created with @code{make-music}) are extracted with
1429 @code{ly:music-property}, a new key-value pair to change the
1430 font size is prepended to the property list with the
1431 @code{acons} Scheme function, and the result is finally
1432 written back with @code{set!}.  The last element of the
1433 @code{let} block is the return value, @code{m} itself.
1434
1435 @end ignore
1436
1437
1438 @node Difficult tweaks
1439 @section Difficult tweaks
1440
1441 There are a few classes of difficult adjustments.
1442
1443 @itemize
1444
1445
1446 @item
1447 One type of difficult adjustment involves the appearance of
1448 spanner objects, such as slurs and ties.  Usually, only one
1449 spanner object is created at a time, and it can be adjusted with
1450 the normal mechanism.  However, occasionally a spanner crosses a
1451 line break.  When this happens, the object is cloned.  A separate
1452 object is created for every system in which the spanner appears.
1453 The new objects are clones of the original object and inherit all
1454 properties, including @code{\override}s.
1455
1456
1457 In other words, an @code{\override} always affects all pieces of a
1458 broken spanner.  To change only one part of a spanner at a line break,
1459 it is necessary to hook into the formatting process.  The
1460 @code{after-line-breaking} callback contains the Scheme procedure that
1461 is called after the line breaks have been determined and layout
1462 objects have been split over different systems.
1463
1464 In the following example, we define a procedure
1465 @code{my-callback}.  This procedure
1466
1467 @itemize
1468 @item
1469 determines if the spanner has been split across line breaks
1470 @item
1471 if yes, retrieves all the split objects
1472 @item
1473 checks if this grob is the last of the split objects
1474 @item
1475 if yes, it sets @code{extra-offset}.
1476 @end itemize
1477
1478 This procedure is installed into @rinternals{Tie}, so the last part
1479 of the broken tie is repositioned.
1480
1481 @lilypond[quote,verbatim,ragged-right]
1482 #(define (my-callback grob)
1483    (let* (
1484           ;; have we been split?
1485           (orig (ly:grob-original grob))
1486
1487           ;; if yes, get the split pieces (our siblings)
1488           (siblings (if (ly:grob? orig)
1489                         (ly:spanner-broken-into orig)
1490                         '())))
1491
1492      (if (and (>= (length siblings) 2)
1493               (eq? (car (last-pair siblings)) grob))
1494          (ly:grob-set-property! grob 'extra-offset '(-2 . 5)))))
1495
1496 \relative {
1497   \override Tie.after-line-breaking =
1498   #my-callback
1499   c''1 ~ \break
1500   c2 ~ 2
1501 }
1502 @end lilypond
1503
1504 @noindent
1505 When applying this trick, the new @code{after-line-breaking} callback
1506 should also call the old one, if such a default exists.  For example,
1507 if using this with @code{Hairpin}, @code{ly:spanner::kill-zero-spanned-time}
1508 should also be called.
1509
1510
1511 @item
1512 Some objects cannot be changed with @code{\override} for
1513 technical reasons.  Examples of those are @code{NonMusicalPaperColumn}
1514 and @code{PaperColumn}.  They can be changed with the
1515 @code{\overrideProperty} function, which works similar to @code{\once
1516 \override}, but uses a different syntax.
1517
1518 @example
1519 \overrideProperty
1520 Score.NonMusicalPaperColumn       % Grob name
1521   . line-break-system-details     % Property name
1522   . next-padding                  % Optional subproperty name
1523   #20                             % Value
1524 @end example
1525
1526 Note, however, that @code{\override}, applied to
1527 @code{NonMusicalPaperColumn} and @code{PaperColumn}, still works as
1528 expected within @code{\context} blocks.
1529
1530 @end itemize
1531
1532 @node LilyPond Scheme interfaces
1533 @chapter LilyPond Scheme interfaces
1534
1535 This chapter covers the various tools provided by LilyPond to help
1536 Scheme programmers get information into and out of the music streams.
1537
1538 TODO -- figure out what goes in here and how to organize it