Re: Change all instances of \partcombine to \partCombine in the documentation (issue 326870043 by pkx1...@gmail.com)
Reviewers: phileholmes_googlemail.com, dak, Carl, Message: On 2017/07/10 16:00:36, dak wrote: On 2017/07/10 15:38:52, Carl wrote: > On 2017/07/10 14:09:53, dak wrote: > > > https://codereview.appspot.com/326870043/diff/1/Documentation/snippets/changing-partcombine-texts.ly > > File Documentation/snippets/changing-partcombine-texts.ly (right): > > > > > https://codereview.appspot.com/326870043/diff/1/Documentation/snippets/changing-partcombine-texts.ly#newcode24 > > Documentation/snippets/changing-partcombine-texts.ly:24: \partCombine > > On 2017/07/10 12:50:12, PhilEHolmes wrote: > > > The best way to change snippets is to edit the LSR and then > > > follow the CG instructions for transferring those changes over > > > to the docs. HTH. > > This is not an option since snippets in the LSR are supposed to be > > valid for an older version of LilyPond. > > Instead you have to rely on the convert-ly run that makelsr.py > > does. > I understood that the CG also says you can place an edited version > of the snippet in Documentation/snippets/new with a lilypond version > of the current development version. Is this incorrect? This is correct but causes significant followup maintenance work as it creates snippet versions maintained separately from the LSR. For things that are successfully covered by convert-ly rules it does not make sense to engage this mechanism. This particularly concerns _bulks_ of snippets. Maybe I am being over-optimistic, but I thought that with makelsr.py running the convert script and so updating the version number that snippets without any convert rules needed would stay at a version compatible with the LSR and so while we would have a number fo additional snippets in the LP repo compared to LSR, the version number would facilitate all this working correctly. James Description: Change all instances of \partcombine to \partCombine in the documentation Issue 4603 (2 of 3) All instances of \partcombine in ../Documentation (including translated and snippets) have been changed to \partCombine. Please review this at https://codereview.appspot.com/326870043/ Affected files (+396, -396 lines): M Documentation/ca/notation/rhythms.itely M Documentation/ca/notation/simultaneous.itely M Documentation/ca/usage/updating.itely M Documentation/cs/usage/updating.itely M Documentation/de/notation/fretted-strings.itely M Documentation/de/notation/input.itely M Documentation/de/notation/rhythms.itely M Documentation/de/notation/simultaneous.itely M Documentation/de/texidocs/combining-two-parts-on-the-same-staff.texidoc M Documentation/de/texidocs/partcombine-and-autobeamoff.texidoc M Documentation/de/usage/updating.itely M Documentation/es/notation/fretted-strings.itely M Documentation/es/notation/input.itely M Documentation/es/notation/rhythms.itely M Documentation/es/notation/simultaneous.itely M Documentation/es/notation/vocal.itely M Documentation/es/texidocs/changing-partcombine-texts.texidoc M Documentation/es/texidocs/combining-two-parts-on-the-same-staff.texidoc M Documentation/es/texidocs/partcombine-and-autobeamoff.texidoc M Documentation/es/usage/updating.itely M Documentation/fr/notation/fretted-strings.itely M Documentation/fr/notation/input.itely M Documentation/fr/notation/rhythms.itely M Documentation/fr/notation/simultaneous.itely M Documentation/fr/notation/vocal.itely M Documentation/fr/texidocs/combining-two-parts-on-the-same-staff.texidoc M Documentation/fr/texidocs/partcombine-and-autobeamoff.texidoc M Documentation/fr/usage/updating.itely M Documentation/hu/usage/updating.itely M Documentation/it/notation/input.itely M Documentation/it/notation/rhythms.itely M Documentation/it/notation/simultaneous.itely M Documentation/it/notation/vocal.itely M Documentation/it/texidocs/changing-partcombine-texts.texidoc M Documentation/it/texidocs/combining-two-parts-on-the-same-staff.texidoc M Documentation/it/texidocs/partcombine-and-autobeamoff.texidoc M Documentation/it/usage/updating.itely M Documentation/ja/notation/fretted-strings.itely M Documentation/ja/notation/input.itely M Documentation/ja/notation/rhythms.itely M Documentation/ja/notation/simultaneous.itely M Documentation/ja/usage/updating.itely M Documentation/ly-examples/sesto-piano.ly M Documentation/notation/fretted-strings.itely M Documentation/notation/input.itely M Documentation/notation/rhythms.itely M Documentation/notation/simultaneous.itely M Documentation/notation/vocal.itely M Documentation/snippets/changing-partcombine-texts.ly M Documentation/snippets/combining-two-parts-on-the-same-staff.ly M Documentation/snippets/new/combining-two-parts-on-the-same-staff.ly M Documentation/snippets/partcombine-and-autobeamoff.ly M Documentation/snippets/two--partcombine-pairs-on-one-staff.ly M Documentation/snippets/vocal-ensemble-template-with-automatic-piano-reduction.ly M
Re: Change all instances of \partcombine to \partCombine in the documentation (issue 326870043 by pkx1...@gmail.com)
On 2017/07/10 15:38:52, Carl wrote: On 2017/07/10 14:09:53, dak wrote: > https://codereview.appspot.com/326870043/diff/1/Documentation/snippets/changing-partcombine-texts.ly > File Documentation/snippets/changing-partcombine-texts.ly (right): > > https://codereview.appspot.com/326870043/diff/1/Documentation/snippets/changing-partcombine-texts.ly#newcode24 > Documentation/snippets/changing-partcombine-texts.ly:24: \partCombine > On 2017/07/10 12:50:12, PhilEHolmes wrote: > > The best way to change snippets is to edit the LSR and then > > follow the CG instructions for transferring those changes over > > to the docs. HTH. > This is not an option since snippets in the LSR are supposed to be > valid for an older version of LilyPond. > Instead you have to rely on the convert-ly run that makelsr.py > does. I understood that the CG also says you can place an edited version of the snippet in Documentation/snippets/new with a lilypond version of the current development version. Is this incorrect? This is correct but causes significant followup maintenance work as it creates snippet versions maintained separately from the LSR. For things that are successfully covered by convert-ly rules it does not make sense to engage this mechanism. This particularly concerns _bulks_ of snippets. https://codereview.appspot.com/326870043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Change all instances of \partcombine to \partCombine in the documentation (issue 326870043 by pkx1...@gmail.com)
On 2017/07/10 14:09:53, dak wrote: https://codereview.appspot.com/326870043/diff/1/Documentation/snippets/changing-partcombine-texts.ly File Documentation/snippets/changing-partcombine-texts.ly (right): https://codereview.appspot.com/326870043/diff/1/Documentation/snippets/changing-partcombine-texts.ly#newcode24 Documentation/snippets/changing-partcombine-texts.ly:24: \partCombine On 2017/07/10 12:50:12, PhilEHolmes wrote: > If files in the snippets directory are changed, the changes will be reverted as > soon as anyone runs makelsr. The best way to change snippets is to edit the LSR > and then follow the CG instructions for transferring those changes over to the > docs. HTH. This is not an option since snippets in the LSR are supposed to be valid for an older version of LilyPond. Instead you have to rely on the convert-ly run that makelsr.py does. I understood that the CG also says you can place an edited version of the snippet in Documentation/snippets/new with a lilypond version of the current development version. Is this incorrect? https://codereview.appspot.com/326870043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Change all instances of \partcombine to \partCombine in the documentation (issue 326870043 by pkx1...@gmail.com)
https://codereview.appspot.com/326870043/diff/1/Documentation/snippets/changing-partcombine-texts.ly File Documentation/snippets/changing-partcombine-texts.ly (right): https://codereview.appspot.com/326870043/diff/1/Documentation/snippets/changing-partcombine-texts.ly#newcode24 Documentation/snippets/changing-partcombine-texts.ly:24: \partCombine On 2017/07/10 12:50:12, PhilEHolmes wrote: If files in the snippets directory are changed, the changes will be reverted as soon as anyone runs makelsr. The best way to change snippets is to edit the LSR and then follow the CG instructions for transferring those changes over to the docs. HTH. This is not an option since snippets in the LSR are supposed to be valid for an older version of LilyPond. Instead you have to rely on the convert-ly run that makelsr.py does. https://codereview.appspot.com/326870043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Change all instances of \partcombine to \partCombine in the documentation (issue 326870043 by pkx1...@gmail.com)
A note on snippets. https://codereview.appspot.com/326870043/diff/1/Documentation/snippets/changing-partcombine-texts.ly File Documentation/snippets/changing-partcombine-texts.ly (right): https://codereview.appspot.com/326870043/diff/1/Documentation/snippets/changing-partcombine-texts.ly#newcode24 Documentation/snippets/changing-partcombine-texts.ly:24: \partCombine If files in the snippets directory are changed, the changes will be reverted as soon as anyone runs makelsr. The best way to change snippets is to edit the LSR and then follow the CG instructions for transferring those changes over to the docs. HTH. https://codereview.appspot.com/326870043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
