Marc Hohl <m...@hohlart.de> writes: > Am 23.09.2012 14:40, schrieb James: >> >> From a novice's point of view q on the face of it is handy, but handy >> in the sense that some of the LSR hacks are handy, it just seems so >> unlike/inconsistent with any of the other commands we use in LP. I >> don't personally have any feelings about whether q is good/bad, I can >> see it certainly makes typing quicker, what I was wondering was is the >> q 'function' holding back and/or preventing other parts of the .ly >> language from being improved/more streamlined in the lexer & parser >> work that David is working on. > Good point. And basically, I support the idea of enhancing the > \repeat ... { stuff } construct – I merely wanted to show that > there are situations where the repeat construct would not work.
Just in case people are worrying about q: I have pretty much expunged all of its involvement with the parser. It is not a maintenance burden either. The code supporting it is quite separate from the parser itself and runs either when explicitly called, or when music is placed in a score. Regarding future parser work, this is a non-issue. Making isolated durations carry meaning, in contrast, would consist of one external component similar to q, but it would also heavily involve the parser itself. The challenge would not be in what to create in the music expression either: like with q, something quite straightforward would likely work fine. The challenge would be to deal with all the resulting ambiguities in a manner that makes sense to parser and humans alike. -- David Kastrup _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user