Re: Abbreviation for markup?

[Shane Brandes]

I really don't believe any blame ought to be cast as yet or at all.
This is after all a weekend and many people are off doing other
things. And quite frankly when scheme gets mentioned many of us non
programmer types look at it and might get the drift of what a bit of
code does but are less liable to have the knowledge to rub those
sticks together to get something useful.
Anyway for annoying repetitious junk it is nice to construct a
variable Which looks like what was suggested. But the variable can be
any short non syntactical bit of, what if the word fooness? I like to
use \w or the like so that it becomes efficient to add it into the
code as you work through the piece.

Shane



On Sun, Jan 29, 2012 at 1:00 PM, David Kastrup <address@hidden> wrote:
> Helge Kruse <address@hidden> writes:
>
>> Am 29.01.2012 11:32, schrieb David Kastrup:
>>>> Is there a way with a music-function or something similar to define an
>>>> abbreviation?
>>>>
>>>> {
>>>>    r4_\markup \concat \vcenter { D\sharp } r4 c'' dis' |
>>>>    a'_\markup \concat \vcenter { D\flat } b' c'' d' |
>>>> }
>>>>
>>>> I would like to do it somehow like this:
>>>>
>>>> {
>>>>    r2\setlever{ D\sharp } r4 c'' dis' |
>>>>    a'\setlever{ D\flat } b' c'' d' |
>>>> }
>>>
>>> You have the crossing of two domains here: music and markup.  Having a
>>> markup command argument is only possible inside of markup, so there are
>>> two possibilities of syntax:
>>>
>>> r2\setlever \markuplist { D\sharp }
>>>
>>> (note that the application of concat and vcenter suggests a markup list
>>> being in use here).
>>>
>>> r2_\markup \setlever { D\sharp }
>>>
>>> and actually, since the namespace of markup functions and music
>>> functions is separate, you could support _both_ at the same time, one
>>> with music (event) function, one with a markup function.  This would be
>>> something like
>>> setlever =
>>> #(define-event-function (parser location pedal) (markup-list?)
>>>    #{ _\markup \concat \vcenter #pedal })
>>>
>>> for the event variant (#1), and
>>>
>>> (define-markup-function (layout props pedal) (markup-list?)
>>>    (interpret-markup layout props
>>>      #{ \markup \concat \vcenter #pedal }))
>>>
>>> for the markup function variant (#2).
>>>
>>> So you can't avoid switching into markup mode either for your command
>>> itself, or at least for its argument explicitly.
>>>
>>
>> Thanks for reply.
>>
>> I tried to make minimal examples with this proposal. I am not
>> experienced with Scheme, so I don't know why this does not work. I
>> append the ly code snippets and Lilypond output at the end.
>>
>> Your help is very appreciated if there is a solution for this
>> convenience approach. But if it is not possible with an appropriate
>> effort I admit it's not that important since it's just an
>> abbreviation.
>>
>> Thanks,
>> Helge
>>
>>
>> \version "2.15.27"
>>
>> (define-markup-function (layout props pedal) (markup-list?)
>>   (interpret-markup layout props
>>     #{ \markup \concat \vcenter #pedal }))
>>
>> {  a'_\markup \setlever { D\flat } b' c'' d'  }
>
> Several typos.  Try
>
> \version "2.15.27"
>
> #(define-markup-command (setlever layout props pedal) (markup-list?)
>  (interpret-markup layout props
>    #{ \markup \concat \vcenter { #pedal } #}))
>
> {  a'_\markup \setlever { D\flat } b' c'' d'  }
>
> I actually am somewhat surprised it needs the braces around #pedal: I
> thought I had catered for that in the parser.
>
>> \version "2.15.27"
>>
>> setlever =
>> #(define-event-function (parser location pedal) (markup-list?)
>>   #{ _\markup \concat \vcenter #pedal })
>>
>> {  r4\setlever \markuplist { D\sharp } r4 c'' dis'  }
>
> In a similar vein, a few typos here:
>
> \version "2.15.27"
>
> setlever =
> #(define-event-function (parser location pedal) (markup-list?)
>  #{ _\markup \concat \vcenter { #pedal } #})
>
> {  r4\setlever \markuplist { D\sharp } r4 c'' dis'  }
>
>
> I am somewhat disappointed that apparently no other, somewhat more
> experienced user bothered trying this out and fixing the rather basic
> typos with some experiment, instead relying on developers to spend even
> more time for getting this right.
>
> We have a long way to go before we have a working community, and the
> recently more popular choice of blaming the developers for that is
> myopic, as somebody needs to invest the time for developing LilyPond as
> well if users are to profit from it.
>
> --
> David Kastrup
>
>
> _______________________________________________
> lilypond-user mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/lilypond-user