Jan-Peter Voigt <jp.vo...@gmx.de> writes: >> On 08.07.2014 13:58, Jan-Peter Voigt wrote: >>> I also stumbled sometimes ove this behaviour, but I think it is not a >>> "real" bug. If the parser has a list? predicate, it looks for >>> dot-notation. But if it gets a custom predicate, it will not do so. >>> Am I right, David?
No. If we have some Word in the place of a function argument, LilyPond tries interpreting it as a string first. If the predicate refuses to accept that, the next try is as a one-element symbol list. If that gets accepted, the parser checks whether this symbol list can be extended with .AnotherWord following. If the predicate refuses a symbol list, however, LilyPond tries feeding it a single symbol before giving up. >>> IIUC some predefined predicates (list?, string?, ly:duration?, >>> ly:pitch?, ...) are handled in a special way to allow shorter input, >>> but this is not "seen" by the parser, if they are wrapped in a custom >>> predicate. > > ... o dear ... > my mail was delayed one day. But thats not too bad, as the other answers > are much more helpful. > Still, wrapped predicates do not get any special handling by th parser. No predicate at all gets special handling by the parser in music functions any more (as of issue 3618, version 2.17.29). You can wrap them all you want. LilyPond actually calls the predicates (often several times, sometimes on partially parsed input) to make its parsing decisions. But then that change has not had a lot of publicity: you'll see that (apart from administrative comments) I have been the only commenter on issue and code review. Things are different for markup command arguments: those have not gotten the whole treatment that music/scheme function arguments have. It would be a completely different bag of tricks to do so in markup mode. -- David Kastrup _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
