Re: RFC: \hideNote

[David Kastrup]

Graham Percival <address@hidden> writes:

> On Tue, Nov 01, 2011 at 09:35:39AM -0400, Kieren MacMillan wrote:
>> > \hideNote
>> > \hideNotes
>> 
>> I thought we had settled on \functionOn and \functionOff (e.g.,
>> \sustainOn and \sustainOff).
>> So we should have \hideNotesOn and \hideNotesOff, right? Then
>> \hideNote could stand for "\once \hideNotesOn".
>
> I'm against this kind of renaming.  We'll probably be changing the
> names in GLISS, so let's not annoy users by changing the syntax
> now and then changing it again in 6-12 months.
>
> Besides, I can't make any release at the moment, and we've already
> had a syntax change for 2.15.17, so trying to make this change
> right now will put us squarely back where we were 2 weeks ago,
> when David and Mike wasted hours and days playing with git and
> convert-ly and stuff.
>
> If two of our best developers can't handle a second convert-ly
> change in the same release cycle

Tut tut.  There was no problem on my side, and Mike's changes were for a
different convert-ly version number than mine, even though there was no
release between us (his rules were lagging a few versions behind, curing
a non-fatal semantics change from a few versions back).  The problem
rather was with getting this stuff with incompatible syntax changes
nicely through dev/staging.  I could have put them straight into master,
and there would have been no problem.

> , then I think it would be absolute cruelty to ask a new contributor
> to attempt the same.

Well, yes.  The staging problem in connection with merges remains, but I
would offer to do the process of making a suitable merge commit with
convert-ly.  Once we get this process working reasonably, we can decide
about whether it is worth the trouble and document it.  Or generally
wrap the changes into a single commit.  Since convert-ly tends to touch
mostly different files than the actual syntax change, this is not likely
to cause all too much confusion.  The disadvantage is that once the
whole has become a single commit, it is inconvenient to fix or review
the parts of it.

Anyway, the problem at the moment is rather that VERSION is at 2.15.17,
and convertrules.py is at 2.15.17, and has been run and applied already.
So there are files with version number 2.15.17, and convert-ly will not
touch them again if you add new 2.15.17 rules to convertrules.py.

If you add rules for 2.15.18, once convert-ly is run, lilypond will
complain when compiling files that have a version lying in the future
(as far as it is concerned).

-- 
David Kastrup