David Sumbler <da...@aeolia.co.uk> writes:
> On Sun, 2018-04-08 at 16:56 +0200, David Kastrup wrote:
>> David Sumbler <da...@aeolia.co.uk> 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.
--
David Kastrup
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
