Hi folks, there is still the big convert-to-single-path-override patch pending, how available in dev/syntax and discussed in <URL:http://code.google.com/p/lilypond/issues/detail?id=2934>.
It is non-Patchy-checkable since Rietveld does not accept diffs of that size. It runs make test fine, and I am currently running make doc on it as well. If we are going through with this one, it means that the override/revert/overrideProperty syntax presented to users is fundamentally different from before. It also means a hard cut in syntax for \overrideProperty: the old syntax will no longer work. The builtin commands \override and \revert, much more often used, will have a grace period where both old and new syntax will work fine. Fading the old syntax out can likely be done in "baby steps" meaning deprecating for 2.18, warning for 2.20, removing support for 2.22. In terms of compatibility, this is not the hottest sale: several music functions change interface incompatibly. To a much more understandable form. I am not enthused about the tweak-like commands that name a manipulated property at the front, ostensibly a grob path at the end as an alternative to tweaked music. \alterBroken, with issue <URL:http://code.google.com/p/lilypond/issues/detail?id=2932> is probably the worst offender here. On the other hand, this favors the use as a tweak rather than an override, and for that the syntax is clearly fine. The incompatible changes are unsavory, but they concern rarely used music functions. Indeed, issue 2934 only tackled \overrideProperty of those, the rest having been brought in line in other issues, and \override/\revert maintaining backwards compatibility right now. The translations for 2.16.1 are pretty much through, and I merged into master again. There still is the regression in issue 2926 "divisioMaior broke" <URL:http://code.google.com/p/lilypond/issues/detail?id=2926> open, but it does not look like we'll have a convincingly discussed and tested solution available soon. So I'll try writing up a "changes" section just pointing to the "Fixed_2_16_1" issues in the bug tracker on Monday. Translating that should not pose much of a problem. And if we don't get translations for that in time, it is not all that much of a concern since it is clear that we still will need a 2.16.2 in due time, possibly in three weeks or so. So I'd aim for getting 2.16.1 closed on Wednesday or so. At that time, the next countdown will just have ended. I'd want to flush this syntax change in at that time. There is still the option to just put in the \overrideProperty change first, but then it will have incompatible syntax with \override/\revert. Which is not totally tragic since it has been inconsistent for all but the last week. However, if we want to go through with this kind of change, we will also need quite a bit of documentation, and it seems rather pointless to document a inconsistent interfaces when the actual target is to have both builtin as well as music-function-implemented commands be presented with a uniform interface. There is also something to be said for compressing all the path-related interface changes into a single convert-ly rule so that we don't have to distinguish 2.17.6 syntax, 2.17.7 syntax, 2.17.8 syntax in a major way. People having second thoughts are welcome to check out the state in the dev/syntax branch. Its files tell the story pretty well. Here is the diff of one file that has 73% of changed lines when running convert-ly: diff --git a/input/regression/line-arrows.ly b/input/regression/line-arrows.ly index affd3a7..1b3bccc 100644 --- a/input/regression/line-arrows.ly +++ b/input/regression/line-arrows.ly @@ -2,26 +2,26 @@ texidoc = "Arrows can be applied to text-spanners and line-spanners (such as } -\version "2.16.0" +\version "2.17.6" \paper { ragged-right = ##t } \relative c'' { - \override TextSpanner #'bound-padding = #1.0 - \override TextSpanner #'style = #'line - \override TextSpanner #'(bound-details right arrow) = ##t - \override TextSpanner #'(bound-details left text) = #"fof" - \override TextSpanner #'(bound-details right text) = #"gag" - \override TextSpanner #'(bound-details right padding) = #0.6 + \override TextSpanner.bound-padding = #1.0 + \override TextSpanner.style = #'line + \override TextSpanner.bound-details.right.arrow = ##t + \override TextSpanner.bound-details.left.text = #"fof" + \override TextSpanner.bound-details.right.text = #"gag" + \override TextSpanner.bound-details.right.padding = #0.6 - \override TextSpanner #'(bound-details right stencil-align-dir-y) = #CENTER - \override TextSpanner #'(bound-details left stencil-align-dir-y) = #CENTER + \override TextSpanner.bound-details.right.stencil-align-dir-y = #CENTER + \override TextSpanner.bound-details.left.stencil-align-dir-y = #CENTER - \override Glissando #'(bound-details right arrow) = ##t - \override Glissando #'arrow-length = #0.5 - \override Glissando #'arrow-width = #0.25 + \override Glissando.bound-details.right.arrow = ##t + \override Glissando.arrow-length = #0.5 + \override Glissando.arrow-width = #0.25 a8\startTextSpan gis8 a4 b4\glissando b,4 | g' c\stopTextSpan c With regard to performance, not having to interleave the Scheme reader and interpreter with the LilyPond parser seems to be actually an advantage. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
