fix CueEndClef with parenthesized ClefModifier

fix CueEndClef with parenthesized ClefModifier

If the main clef has a parenthesized or bracketed ClefModifier, ending a
cue now prints those parentheses/brackets.

Contains regtest.

This was reported at the german speaking LilyPond forum: https://lilypondforum.de/index.php?topic=324

[Malte Meyn, 2018-06-20 19:04:31]

https://codereview.appspot.com/353720043/diff/1/input/regression/cue-clef-aft...
File input/regression/cue-clef-after-barline.ly (right):

https://codereview.appspot.com/353720043/diff/1/input/regression/cue-clef-aft...
input/regression/cue-clef-after-barline.ly:8: Solo = \relative {
Ooops … These whitespace fixes (introduced by Frescobaldi’s autoformat) have
nothing to do with the bug and patch itself.

https://codereview.appspot.com/353720043/diff/1/input/regression/cue-clef-tra...
File input/regression/cue-clef-transposition-optional.ly (right):

https://codereview.appspot.com/353720043/diff/1/input/regression/cue-clef-tra...
input/regression/cue-clef-transposition-optional.ly:1: \version "2.21.0"
When should the version number be updated? Only if new features are used? Or
should it reflect the last changes to the file?

https://codereview.appspot.com/353720043/diff/1/scm/parser-clef.scm
File scm/parser-clef.scm (right):

https://codereview.appspot.com/353720043/diff/1/scm/parser-clef.scm#newcode177
scm/parser-clef.scm:177: (clefTranspositionFormatter .
cueClefTranspositionFormatter)
Do we need this? I think so. Though it has nothing to do with the bug.

[simon.albrecht, 2018-06-20 20:15:24]

On 20.06.2018 21:04, lilypond@maltemeyn.de wrote:
>
https://codereview.appspot.com/353720043/diff/1/input/regression/cue-clef-tra...

>
> input/regression/cue-clef-transposition-optional.ly:1: \version "2.21.0"
> When should the version number be updated? Only if new features are
> used? Or should it reflect the last changes to the file? 

The latter: It should reflect the first version containing the latest 
changes to the file.
Sorry I can’t find the CG reference right now.

Best, Simon

[dan_faithful.be, 2018-06-20 22:51:05]

On Jun 20, 2018, at 16:15, Simon Albrecht <simon.albrecht@mail.de> wrote:
> 
> On 20.06.2018 21:04, lilypond@maltemeyn.de wrote:
>>
https://codereview.appspot.com/353720043/diff/1/input/regression/cue-clef-tra...

>> input/regression/cue-clef-transposition-optional.ly:1: \version "2.21.0"
>> When should the version number be updated? Only if new features are
>> used? Or should it reflect the last changes to the file? 
> 
> The latter: It should reflect the first version containing the latest changes
to the file.
> Sorry I can’t find the CG reference right now.

Looking n CG 2.19.80, I can’t find it either, though I found different guidance
on the use of \version in documentation snippets.

I am curious why you recommend this, as I’ve been doing it differently in the
recent past.  I've added regression tests which passed when I tested them with
2.19.80, so that is the \version I specified when I contributed them to LilyPond
2.21.0.  It was convenient to be able to run them with 2.19.80 without getting a
“program too old” error.
— 
Dan

[dak, 2018-06-21 07:29:30]

Simon Albrecht <simon.albrecht@mail.de> writes:

> On 20.06.2018 21:04, lilypond@maltemeyn.de wrote:
>>
https://codereview.appspot.com/353720043/diff/1/input/regression/cue-clef-tra...
>>
>> input/regression/cue-clef-transposition-optional.ly:1: \version "2.21.0"
>> When should the version number be updated? Only if new features are
>> used? Or should it reflect the last changes to the file? 
>
> The latter: It should reflect the first version containing the latest
> changes to the file.

It usually does because that's easiest to do/verify and we don't go back
in time beyond last stable.  But the hard rule is not to write version
numbers that would crash.

-- 
David Kastrup