Re: Optional args in event-function not working with 2.17.6 ?

[David Kastrup]

Thomas Morley <address@hidden> writes:

> I was working on
> http://lists.gnu.org/archive/html/lilypond-user/2012-11/msg00185.html
> and wrote a event-function as a template for custom-script-signs.
> This function uses some optional arguments and works as expected in 2.16.0
> But not in 2.17.6
> What am I missing?
>
> newScript =
> #(define-event-function (parser location lst scaling strg) ((list? '(0
> 0 0)) (boolean? #f) string?)
>
> grave = \newScript #'(-1 0 0) ##t "`"
> acute = \newScript #'(0 1 0) ##t "´"
> threePoints = \newScript "…"
> noName = \newScript "@"

I'd have expected these use cases to work.  However, the interface is a
bit shaky since a string that can be parsed as a symbol will be
converted into a list of symbols.  So a string like "a" or "xxx" would
fit the list? predicate.  How do we get out here?

a) The obvious solution is to use number-list? rather than list? as a
   predicate, and we won't get fed a symbol list.

But the behavior is unexpected, so it might be better to amend it in
addition.  How to amend it?

b) "…" does not really look like an identifier even though it obeys
LilyPond's rules for unquoted word syntax.  Only allow ASCII characters
in things auto-converted into symbol lists.

c) That does not help with "xxx".  Only allow unquoted words to
autoconvert into symbol lists.  I am actually working on this already
since I am not satisfied with input/regression/lyric-tweak.ly (writing
quotes seems like it should be sufficient; having to write \markup seems
weird).  But I am not finished yet, and it would have warranted getting
finished before discussion.  I have kept the "changes.tely" entry vague
enough that it would cover this behavior as well.  Cough cough.

Solution c would make quoted and unquoted strings unequivalent.
Solution b would stop the equivalence between what can be an unquoted
word and what can be a symbol.

I am not decided about b.  It would not have helped you much.  You'd
still have gotten failures, but the problem would likely have been
easier to recognize.  Possibly with both b and c in place, it would
become easy to guess what happened in the remaining failure cases.

What do you think?

-- 
David Kastrup