lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Case of 'c' in partcombine


From: Charles Winston
Subject: Re: Case of 'c' in partcombine
Date: Thu, 25 May 2017 13:22:24 -0400

> On May 25, 2017, at 11:54 AM, Charles Winston <address@hidden> wrote:
> 
> 
>> On May 25, 2017, at 11:48 AM, Carl Sorensen <address@hidden> wrote:
>> 
>> On 5/25/17 8:40 AM, "lilypond-devel on behalf of Charles Winston"
>> <address@hidden on behalf of
>> address@hidden> 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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]