Janek Warchoł <janek.lilyp...@gmail.com> writes: > On Thu, Oct 4, 2012 at 10:28 AM, David Kastrup <d...@gnu.org> wrote: >> [..] >> So if we want to avoid this kind of fallacy, there are a few ways out. >> I decided to take a reasonably safe route by foregoing lookahead for '.' >> unless explicitly told so. How does a function tell LilyPond to look >> for a string sequence like that in a function argument? Of course, >> using the predicate. The function sees a STRING token with an >> associated string value `val' and it checks whether the predicate would >> be fine with accepting val. If so, the string gets accepted and >> LilyPond does not look further. > > Sounds reasonable to me (assuming i understood it correctly) > >> One rather sobering consequence is that any command accepting a grob >> specification will _not_ be able to take a proper string generated in >> Scheme using #... for it. It will always require at least a _list_ of >> strings. This is consistent with 2.16 behavior of \override/\revert etc >> where you had to at least use $... to get a string into this place (it >> is not consistent with the current more lenient 2.17 behavior, but it is >> not likely anybody noticed so far). > > I don't understand this part. Small example please?
Assuming \override-like-function is defined with an argument of type symbol-list?, you get \override-like-function #"Slur" ... -> argument error \override-like-function #"Voice" . #"Slur" -> syntax error \override-like-function "Slur" ... -> #'(Slur) \override-like-function "Voice" . "Slur" ... -> #'(Voice Slur) \override-like-function Slur ... -> #'(Slur) \override-like-function Voice.Slur ... -> #'(Voice Slur) \override-like-function $"Slur" ... -> #'(Slur) \override-like-function $"Voice" . $"Slur" ... -> #'(Voice Slur) #xxx tells LilyPond "please use xxx unchanged without any context-dependent magic". Currently \override _itself_ will accept #"Slur" as one form of a specification, but that behavior is not older than a few weeks, so it is unlikely anybody depends on it, and it would probably make sense to stop it from accepting things that a musicfunction-based simulation would have no access to. > Overall LquiteGTM. Hey, I have not even _started_ with issue/review, so merging is still a bit away. I am just in the state where all regtests pass after a set of back-and-forth commits and I decided to do everything almost, but not quite, entirely unlike before. So I have some heavy rebasing to do, and then rewrite, and then it makes some sense talking again about this. I was just putting forth some preliminary views of what I am doing and why it is taking me a bit longer than anticipated to hammer this into a form -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
