lilypond-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Making a list argument reliably optional


From: David Kastrup
Subject: Re: Making a list argument reliably optional
Date: Thu, 22 Aug 2019 00:41:21 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

Robin Bannister <address@hidden> writes:

>  David Kastrup wrote:
>
>> Could you please post an actual minimal example we
>> could talk about usefully?
>
> OK.  I'm moving, but unsure of the direction.
>
> notnumber.ly is a complete instance of trying to be more specific.
> It breaks at 2.19.39.

That would likely be issue 4798
<https://sourceforge.net/p/testlilyissues/issues/4798/> with one of the
following commits:

commit 34917fefd1167f963c44fbcf47ab7f4184fc4cdc
Author: David Kastrup <address@hidden>
Date:   Thu Mar 10 18:23:48 2016 +0100

    Issue 4798/6: Admit lists starting with UNSIGNED as music function arguments

commit 0453c1df927617386bfd63f22965a72f43b192a8
Author: David Kastrup <address@hidden>
Date:   Sun Mar 13 20:49:49 2016 +0100

    Issue 4798/5: Use key-list? for several music command predicates
    
    This is sort of arbitrary currently but matches the kind of syntax
    accepted by \override/\revert due to their definition in the parser.

commit 77cf1054ff5aeb20978a1586a44f5b95fb365585
Author: David Kastrup <address@hidden>
Date:   Wed Feb 3 19:38:29 2016 +0100

    Issue 4798/4: Parser work for key lists including numbers
    
    This admits key lists containing non-negative numbers into various
    syntactic constructs previously using symbol lists.
    

A number list can be used after this as a function argument, like

\time 3,1 4/4

Or even

\time 4 4/4

A number list counts as not-number?.  So if you are out for a more
specific type of list before a number, you should check for that.  Yes,
this is a feature coming with drawbacks that may be surprising.
Optional argument processing that does not make use of \default relies
on predicates not being misinterpreted, and interpreting some input as a
list (symbol list or number list) is probably the most likely candidate
for unexpected matches.  Optional list arguments should be as specific
as possible for that reason, in a manner that input suitable for the
following non-optional argument cannot be misinterpreted as matching.

Sorry for that.  With great power comes great confusability.

-- 
David Kastrup



reply via email to

[Prev in Thread] Current Thread [Next in Thread]