How to procede with \override/\revert business

[David Kastrup]

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