lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Allow a markup to replace the default LyricHyphen (issue 325470043 b


From: dak
Subject: Re: Allow a markup to replace the default LyricHyphen (issue 325470043 by address@hidden)
Date: Sun, 17 Sep 2017 05:42:58 -0700


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/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]