Copying to a wider distribution of people who only sporadically write on lilypond-devel (I hope I have most of the others covered via lilypond-devel) since I need feedback on this. Issue 2883 <URL:http://code.google.com/p/lilypond/issues/detail?id=2883> deals with a mostly (apart from half a dozen music functions that usually get an extension in functionality at the price of non-upward-compatibility) upwards-compatible change in syntax that may have drastic repercussions on what syntax we want people to use.
In a nutshell, things like \override Staff.TimeSignature #'bound-details #'left = #42 (it is obvious that I don't quite remember what I am talking about) are equivalent to \override #'(Staff TimeSignature) bound-details.left = #42 or (what we might want to actually promote) \override Staff.TimeSignature bound-details.left = #42 And the same equivalences basically hold when you are calling functions that expect to see a list of symbols as argument. That basically makes it possible to obliterate usage of #' from many LilyPond programs and means that users are not generally required to know the difference between symbols and strings and when to use which. This requires quite a bit more of type-checking in the parser, but it turns out that this is not a performance problem since it beats invoking the Scheme reader and interpreter for such expressions hands down. I need feedback. Read on. James <pkx1...@gmail.com> writes: > I'm trying to run patchy and getting > > > Trying issue 2883 > Warning: something went wrong; omitting patch for issue 2883 > No new patches to test [...] > Can you at least run ./test-patchy and see if you get the same > immediate warning? > > Not asking you to test it, but that you get the same as me. Sure, that's what comment #6 is about <URL:http://code.google.com/p/lilypond/issues/detail?id=2883#c6>. I have checked the regtests myself (you can get this from the origin/dev/syntax branch), they compare fine. (Unfortunately, they already compared fine when the footnote conversion lead to dropped per-Staff footnotes, so either footnotes pass under the radar of the comparison script selecting the graphical comparison candidates, or our regtests are not exhaustive enough.) The doc compilation drops out in the German translation as the pre-2.16 \footnote description throws errors (rather than just being non-working non-sense like it is now) after the conversion. This patch was _supposed_ to be huge (due to a really invasive convert-ly rule) in order to demonstrate the kind of syntax we can consistently use in future if we want to. I'll try reworking the material to a state where the convert-ly conversions will be restricted to those music functions where the new syntax is not upwards-compatible with the previous one. The current state of the branch is dak@lola:/usr/local/tmp/lilypond$ git diff --shortstat origin..HEAD 692 files changed, 7432 insertions(+), 7196 deletions(-) and the contribution of the last convert-ly commit is 687 files changed, 6838 insertions(+), 6879 deletions(-) so there is some leeway for making the _code_ easier reviewable. But the _point_ of the _invasive_ patch and convert-ly rules was to get feedback about what people think about a language change that essentially makes it unnecessary for users to write symbols like #'xxx or to even know the difference between symbols and strings, regardless of whether we are talking about using commands hard-wired into the parser or music functions. And of course also to give \override-like music functions the option to get input like Staff.TimeSignature delivered as #'(Staff TimeSignature) automagically. So far, the attempt to get feedback on this language change has failed spectacularly, but that is the point of the current review at <URL:http://codereview.appspot.com/6635050>. So I'd reask people to look at this change either on the Rietveld review or in git in the origin/dev/syntax branch <URL:http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=shortlog;h=refs/heads/dev/syntax>, in particular the impact of the last commit by running convert-ly. And give their opinion about what does not quite constitute peanuts in the GLISS area. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel