[Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] #4603 change a

Ok, this is really really late but I've taken a look at the output of

git grep '[pP]artCombine'

in the current code base and changing those occurences to partcombine would be way less effort than the other way round: basically most of them are new.

I might be predisposed by lots of exposure to previous code though. The oldest ones to be changed would be partcombineListener (output definitions are not capitalized?), PartcombineMusic, PartcombinePartMusic, printPartcombineTexts.

I am slightly leaning to that change but it would also have to result in Partcombine_engraver, Partcombine_iterator, Partcombine_part_iterator to be consistent. Basically making partcombining one word (wouldn't separate words be rather "combine parts"? The correct spelling of partcombiner would likely be "the part-combiner". Huh).

However that may be: having a large discrepancy without backward compatibility between 2.18 and 2.20 seems like a bad idea since LSR and online help will bomb a lot. We have seen this effect with various backward-compatible but compelling changes in the past: having this in a non-backward-compatible way seems like a bad idea that will cause a whole lot of medium-term pain for little long-term gain.

So I think it would be reasonable to
a) postpone any such changes to 2.21. Since we currently are at a good time to fork off the 2.20 release branch anyway, that does not need to imply a large delay.
b) develop a mechanism for backward compatibility. Reasonably easy for commands, trickier for properties and engravers.

Point b) should be tackled rather fast though, preferably within a reasonable time frame of a), perhaps even before if possible. Depends on how fast we can come up with ideas for making this work.

[issues:#4603] change all occurences of ‘partcombine’ to ‘partCombine’.

Status: Started
Created: Sun Sep 13, 2015 03:17 PM UTC by pkx166h
Last Updated: Mon Jul 10, 2017 10:26 AM UTC
Owner: Charles Winston

On 13/08/15 21:42, Malte Meyn wrote:

Hi list,

the case of the ‘c’ in partcombine is inconsistent, confusing me every
time I use \partcombine(Apart|Chords|…):

\partcombine, \partcombineApart, … but
\partCombineTextsOnNote, \partCombineListener

I would suggest to change all occurences of ‘partcombine’ to ‘partCombine’.

Why not change ‘partCombine’ to ‘partcombine’? Because I looked at the
engravers which use the more ‘natural’ underscore instead of camelCase
for spaces. And in the same way as ‘Cue_clef_engraver’ suggests that
‘cue clef’ are two words (resulting in ‘cueClefGlyph’, not
‘cueclefGlyph’), ‘Part_combine_engraver’ does.

I think that this would be rather easy to change.

Cheers,
Malte

Response to Issue #4603: Syntax change from all instances "partcombine" to "partCombine" and convert-ly rule added to go along with.

http://codereview.appspot.com/323040043 - part 1 of 3

http://codereview.appspot.com/326870043 - part 2 of 3

http://codereview.appspot.com/327970043 - part 3 of 3

Note this will require both a convert.ly and a makelsr.py run to make sure that the patch passes all the tests.

Sent from sourceforge.net because address@hidden is subscribed to https://sourceforge.net/p/testlilyissues/issues/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/testlilyissues/admin/issues/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.

From:	Auto mailings of changes to Lily Issues via Testlilyissues-auto
Subject:	[Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] #4603 change all occurences of ‘partcombine’ to ‘partCombine’.
Date:	Mon, 10 Jul 2017 14:48:05 +0000