Reviewers: nicolas.sceaux,
Message:
This passes regtests. I would tend towards committing in this form in
order to keep commit size to the point. Instead of a separate regtest,
I'd likely walk through scm and ly directories and use this
functionality where appropriate.
ly:parse-string-expression basically copies ly:parse-string, and it
contains a bunch of clutter (like checking a stack that does not appear
to be maintained at the end) which I just replicated.
Maybe this should get weeded out (I don't see the purpose), but it is
not a new problem.
Error messages when parsing #{ #} are less than helpful, origin
information likely similarly.
Again, this is not a new problem, so I tend towards not tackling this in
this patch.
Of course, documentation can be improved quite a bit by making use of
the new functionality. In the interest of not cluttering this into a
single commit, I'd like to do so later.
http://codereview.appspot.com/4974046/diff/1/scm/parser-ly-from-scheme.scm
File scm/parser-ly-from-scheme.scm (right):
http://codereview.appspot.com/4974046/diff/1/scm/parser-ly-from-scheme.scm#newcode36
scm/parser-ly-from-scheme.scm:36: (ly:parser-lookup parser
'$parseStringResult))
On 2011/08/28 08:45:19, nicolas.sceaux wrote:
Maybe a comment could tell where $parseStringResult comes from
I am moving parse-string-result into the C function
ly:parse-string-expression and commenting the respective line there.
Description:
Make #{ #} accept everything an assignment accepts.
This also makes #{ #} return a void music event, and does not create
sequential music if not necessary.
Please review this at http://codereview.appspot.com/4974046/
Affected files:
M input/regression/display-lily-tests.ly
M lily/include/lily-lexer.hh
M lily/include/lily-parser.hh
M lily/lexer.ll
M lily/lily-parser-scheme.cc
M lily/lily-parser.cc
M lily/parser.yy
M scm/parser-ly-from-scheme.scm
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
