https://codereview.appspot.com/325470043/diff/20001/lily/lyric-hyphen.cc File lily/lyric-hyphen.cc (right):
https://codereview.appspot.com/325470043/diff/20001/lily/lyric-hyphen.cc#newcode126 lily/lyric-hyphen.cc:126: Stencil dash_mol (Lookup::round_filled_box (b, 0.8 * lt)); On 2017/09/17 10:16:01, knupero wrote:
Shouldn't the hardcoded 0.8 be replaced by a property?
We have a lot of hardcoded typesetting. Unless a particular need for more flexibility or variation is reported, we tend to keep things to perceived best practice. That also gives us the flexibility to change such values based on the actual situation if that seems warranted, rather than leaving it to the user to optimize each case. Do you see a particular reason why making this configurable might be needed? https://codereview.appspot.com/325470043/diff/20001/scm/define-grobs.scm File scm/define-grobs.scm (right): https://codereview.appspot.com/325470043/diff/20001/scm/define-grobs.scm#newcode1403 scm/define-grobs.scm:1403: (text . '()) On 2017/09/17 10:16:01, knupero wrote:
On 2017/09/16 19:53:56, dak wrote: > That's the default when unset. For properties that may optionally
be set, in
> particular when this default formally does not match the predicate,
I think we
> tend not to explicitly specify it.
Well, omitting it here means that there is no indication in the
internals
reference that LyricHyphen uses that property.
Which is the same with every overridable grob having a text-interface, like, say, ChordName or InstrumentName . If you want to have this policy changed, the way to do that is a separate patch just doing that everywhere, not changing stuff piecemeal. Though since the Internals Reference is already rather large, the enthusiasm for explicitly documenting Grob properties that are left at their interface default will likely not be all that large, particularly since the actual documentation is _not_ specific to the grob but recruited from the respective interface definition. https://codereview.appspot.com/325470043/ _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
