On 3 December 2011 13:59, David Kastrup
<address@hidden> wrote:
We have the following patch in staging (and likely soon in master)
commit d11e23cca2df1267b25c86d96a4dcffa957a7a55
Author: James Lowe <address@hidden>
Date: Sat Dec 3 09:42:02 2011 +0000
Doc: NR 1.6.2 - Staff Symbol
Simplified the \override constructions in @lilypond examples.
A first step for the forthcoming patch for 1935
Agreed with by Trevor and Graham.
diff --git a/Documentation/notation/staff.itely b/Documentation/notation/staff.i
index 052254e..bbf1327 100644
--- a/Documentation/notation/staff.itely
+++ b/Documentation/notation/staff.itely
@@ -431,9 +431,7 @@ staff. For an explanation, refer to the snippet section in
address@hidden
address@hidden,quote,relative=2]
-\new Staff \with {
- \override StaffSymbol #'line-count = #3
-}
+\override Staff.StaffSymbol #'line-count = #3
{ d4 d d d }
address@hidden lilypond
What is the idea behind that?
The idea was that the patch I am working on to document the new 'internal legder lines' meant I wanted to do some re-arranging of the section as well as give new examples incorporating this new feature.
I was making a kind of 'two step' change, so that when I finally presented a significantly updated section it was not including the noise of some simplification of examples.
I'd checked with Trevor and Graham (as the commit messages says) that we were ok with removing a \new Staff { \with ..} construct to just including the 'Staff' in the override (in this case). Functionally it didn't seem to do anything _and_ I had checked by making a full doc build and nothing broke (I did it again this morning too before I pushed).
So all that _should_ have changed was the unnecessary \new Staff { \with } had been removed.
This changes the examples from something
that works standalone to something that bombs out with
lilypond /tmp/xxx.ly
GNU LilyPond 2.15.21
Processing `/tmp/xxx.ly'
Parsing...
/tmp/xxx.ly:1:0: error: syntax error, unexpected \override
\override Staff.StaffSymbol #'line-count = #3
It only works inside of more complex music expressions, and it is rather
bad style to change the Staffsymbol inside of music expressions anyway.
Not sure what 'bad style' means here, but the idea was to simplify the example without unnecessary verbiage in the @lilyponds
For example, it won't work timely if a parallel voice starts with a
\grace, not even if you explicitly instantiate all voices.
Not sure what that has to do with this section in the NR showing how to modify the staff symbol.
Why are changes like that "agreed with" in the light of a "forthcoming
patch"?
Because when I need advise about a change in the documentation style I tend to go to Graham (Doc Meister) and Trevor (much more experienced with Doc than I and helped mentor me too) so as to not give too much noise. I could have just dumped all this in one patch but then have been accused (perhaps) of doing too much in one go.
As I said, it didn't break doc build and I intended to make these changes anyway in the final patch, this was supposed to just keep the doc as it was while I finish working on the much larger patch and make the review process easier.
Nothing sinister about it, and am happy to revert it but don't understand why this is bad. Sure the new example is much 'simpler' than having write all the \new Staff { with }, especially when I as a LP user want to write single system scores where I would probably never ever use \new Staff { \with.