lilypond-user
[Top][All Lists]

## Re: Repeating \markup commands

 From: David Sumbler Subject: Re: Repeating \markup commands Date: Sun, 08 Apr 2018 19:51:04 +0100

```On Sun, 2018-04-08 at 20:26 +0200, David Kastrup wrote:
> David Sumbler <address@hidden> writes:
>
> >
> > On Sun, 2018-04-08 at 16:56 +0200, David Kastrup wrote:
> > >
> > > David Sumbler <address@hidden> writes:
> > >
> > > >
> > > >
> > > > The piece I am setting has a narrator.  For the score I have
> > > > worked
> > > > out
> > > > a way of adding the narrator's short speeches over the music
> > > > which
> > > > gives the appearance I want.
> > > >
> > > > It entails using the same markup commands for every individual
> > > > speech,
> > > > e.g.:
> > > >
> > > > s^\markup { \whiteout \pad-markup #2 "Just listen!" }
> > > >
> > > > (The s is an invisible rest)
> > > >
> > > > It would be nice to be able to do something like:
> > > >
> > > > s^\nar "Just listen!"
> > > >
> > > > How could nar be defined in this case?
> > > Current development version:
> > >
> > > nar = ^\markup \whiteout \pad-markup #2 \etc
> > >
> > > Older stuff:
> > >
> > > nar =
> > > #(define-event-function (parser location m) (markup?)
> > >    #{ ^\markup \whiteout \pad-markup #2 #m #})
> > >
> > > Not that much worse, actually.
> > \version "2.19.81"
> > nar = ^\markup \whiteout \pad-markup #2 \etc
> 2.21.0 to be is required, but for 2.19.81 you can at least omit the
> somewhat cryptic "parser location" parameters.
>
> >
> > Unfortunately the above produces "syntax error, unexpected \etc"
> > The older version works fine.
> >
> > It would be nice to get the newer version to work, because in
> > principle this type of syntax should make it much easier for me to
> > create my own functions in future instead of bothering the list so
> > often.
> It's just a particular kind of event function created from markup, so
> it
> does not make for a lot of uses avoiding an actual Scheme-style
> definition, and they aren't really that hard to do.
>
> In a way, it is funny how far a limited redundant shortcut \etc will
> carry both in the use cases actually covered by it as well as in user
> acceptance.
>
> One reason for the former may be that many music/scheme/event
> functions
> have been intentionally organized in a manner where the most
> important
> argument is last in order to facilitate "chaining" them without
> trailing
> arguments stacking up.  And that argument order is what \etc can work
> with.

My apologies.  I assumed that you meant that the newer syntax would
work in 2.19.81, which is the latest development version available for