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 testlilyissues-a...@lists.sourceforge.net 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.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Testlilyissues-auto mailing list
testlilyissues-a...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/testlilyissues-auto
