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? Overall LquiteGTM. Janek _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
