> On May 25, 2017, at 11:54 AM, Charles Winston <[email protected]> wrote: > > >> On May 25, 2017, at 11:48 AM, Carl Sorensen <[email protected]> wrote: >> >> On 5/25/17 8:40 AM, "lilypond-devel on behalf of Charles Winston" >> <[email protected] on behalf of >> [email protected]> wrote: >> >>> Hey developers, >>> >>> I am working on my first patch‹it is resolving a very simple issue from >>> the tracker. The case of the Œc¹ in partcombine is inconsistent and can >>> result in some confusion. For example: \partcombine, \partcombineApart, >>> and others like this use the lower-case Œc' Š but >>> \partCombineTextsOnNote, \partCombineListener use the camelCase ŒC¹. The >>> suggestion is to change all instances of partcombine to the camelCase >>> partCombine‹not the other way around because the engraver treats ³part² >>> and ³combine² as separate words: ŒPart_combine_engraver¹. >> >> This is an easy patch in terms of functionality, but it will need a >> convert-ly rule because it will break existing scores. That's not a >> reason to avoid doing it; you just need to be aware that the rule will >> need to be made and tested. >>
Am I correct in understanding that the convert-ly rules are defined in python/convertrules.py? So I would have to write rules in this file that convert any “\partcombineSomething” to “partCombineSomething”? And what should I do about existing rules that involve partcombine? For example, there is one rule with the following description: “\\partcombine syntax change to \\newpartcombine”—should I leave this alone? Because the following rule seems to change it back… “\\newpartcombine -> partcombine” Would love some clarification on this. Thanks, Charles _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
