Thomas Morley <[email protected]> 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 _______________________________________________ lilypond-user mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-user
