#5097 Fix programming errors associated with texted HorizontalBracket grobs

[David Nalesnik]

https://codereview.appspot.com/317460043

HorizontalBracket and HorizontalBracketText are both created from the same event. Thus, a tweak of a property not possessed by both grobs (such as 'text or 'thickness) will result in a programming error, unless the tweak is directed at the correct grob.

Example:

\layout {
  \context {
    \Voice
    \consists "Horizontal_bracket_engraver"
  }
}

{
  c'' -\tweak text "foo" \startGroup d'' e'' f''\stopGroup
}

[David Kastrup]

Another case where we just want the cause of the text to be the bracket?

[David Nalesnik]

Changing the cause of the HorizontalBracketText spanner to the HorizontalBracket still leads to the errors (as does setting it to SCM_EOL).. I'm not seeing any option for correcting the programming errors other than directed tweaks.

[David Kastrup]

Well, of course tweaking the text of the bracket grob will still cause the error/warning. But it would also stop appearing to work in spite of the warning. And tweaking thickness will not cause HorizontalBracketText to complain. So that's half of the warnings disappearing, and the other half of the warnings actually pointing out something going wrong.

The proposal was just supposed to make stuff behave more predictably, not more conveniently. Whether that's good enough is another question.

It would also be imaginable that HorizontalBracket gets the text interface and will have its text settings used for initializing those of HorizontalBracketText (unless overridden). That's a lot more handwavy but will probably generally work as expected.

[David Nalesnik]

I would think that it would be good to have output in spite of any warnings, or in this case, programming errors.

To even see them in the log you have to run lilypond with a special flag set, so an ordinary user would have no idea why there was no output.

I'm thinking that the best way to go about correcting this issue is just to make all the text tweaks directed tweaks. Unfortunately, it's cumbersome to tweak HorizontalBracketText,text, but concocting some behind-the-scenes magic to get any text-interface or font-interface tweaks to the right grob seems contrived and error-prone.

To make input more natural, I thought about

\startGroup "some text" c'' d'' \stopGroup

But wouldn't the user then have to write

\startGroup \default
?

(I have considered dispensing with a special grob for the text altogether, simply adding a 'text property to HorizontalBracket, along with the necessary interfaces. However, a separate grob allows easy customization, including alignment along the parent bracket through the self-alignment-interface.)

[Thomas Morley]

Maybe the method in
http://codereview.appspot.com/321730043
may partly help.

At least with adding thickness and text to the properties in horizontal-bracket.cc I got rid of one warning.

The other part may be the method from
https://sourceforge.net/p/testlilyissues/issues/5096/
Not tested, though.

[David Nalesnik]

Issue 5097: reach HorizontalBracketText through directed tweak

HorizontalBracketText is now caused by HorizontalBracket, rather
than the same note-grouping event.

Fix a number of programming errors caused by commit for Issue
5064.

http://codereview.appspot.com/317460043

[Anonymous]

Passes make, make check and a full make doc.

[Anonymous]

Patch on countdown for March 31st.

[Anonymous]

Patch counted down - please push.

[David Nalesnik]

Pushed to staging as commit 8ef5f99e63cc9e52c7c0071cde4d99e057d10329.

[Graham Percival]

Verified, thanks for including an example to check! :)