Re: 2.21 note definition change

[David Kastrup]

David Kastrup <dak@gnu.org> writes:

> Paul Scott <waterhorse@ultrasw.com> writes:
>
>> On 6/23/20 4:01 PM, David Kastrup wrote:
>>> Paul Scott <waterhorse@ultrasw.com> writes:
>>>
>>>> On 6/23/20 2:23 PM, David Kastrup wrote:
>>>>> Paul Scott <waterhorse@ultrasw.com> writes:
>>>>>
>>>>>> The 1st argument for note is now a duration rather than a string.
>>>>>>
>>>>>> I had some scheme definitions which were variations on \tempo.
>>>>>>
>>>>>> I used (string?) for this value before.  What is the new scheme
>>>>>> equivalent?  (duration?)
>>>>> ly:duration?
>>>> Thank you, David.
>>>>
>>>> I believe I had tried that.
>>>>
>>>> Here's my MWE which hopefully will show someone what dumb mistake I'm
>>>> making:
>>>>
>>>> \version "2.21.2"
>>>>
>>>> #(define-markup-command (notetest layout props dur) (ly:duration?)
>>>>    interpret-markup layout props
>>>>    (markup
>>>>     #:note dur #up
>>>>   ))
>>>>
>>>> {
>>>>    \tempo \markup{ Allegro \notetest #4 }
>>>>    c'1
>>>> }
>>>>
>>>> Thank you,
>>> Several.  Is there a reason you use the markup macro rather than
>>> #{ \markup ... #} ?
>> No.  Only that I had working code before
>>> The latter can do the same but is more
>>> straightforward to use when not familiar with Scheme syntax, and you
>>> really make it appear like you aren't.
>> Obviously not enough.  I used to make my living programming in many
>> different languages.
>>> You write interpret-markup ... instead of (interpret-markup ...) .  In
>>> Scheme, every pair of paren conveys meaning.  They aren't syntactic
>>> sugar which you can add or remove.
>>
>>
>> Oops!  All my other code has (interpret-markup ... )
>>
>>> Then you write #up in Scheme.  # in Scheme introduces specially parsed
>>> expressions, such as #(...) for literal vectors, or #{ ... #} for
>>> embedded LilyPond or #t or #f for true and false boolean literals.
>> Another dumb mistake.
>>>
>>> And both LilyPond and (Guile) Scheme are case sensitive: you cannot swap
>>> up and UP.
>>
>> A bug or whatever.  I use lower case for #up and #down in \cueDuring
>> and they work fine.  I have hundreds of working examples.  I am
>> certainly clear on case sensitivity but this one seems to be an
>> exception.
>
> lilypond scheme-sandbox
>
> shows that up and down are defined in the Scheme layer.  I have no idea
> what code is responsible for that, but I'll take a look.

ly/declarations-init.ly:

    % declarations for standard directions
    left = #-1
    right = #1
    up = #1
    down = #-1
    start = #-1
    stop = #1
    smaller = #-1
    bigger = #1
    center = #0

Ouch.

-- 
David Kastrup