On 2013/11/01 20:20:35, dak wrote:
On 2013/10/26 06:37:13, Keith wrote:
> The simplicity is just lovely.
Always hard to tell sarcasm from enthusiasm.
This patch does simplify things -- especially in comparison to the
version that changed behavior based on scale-factors being integral
multiples of things. Only history makes things complicated.
https://codereview.appspot.com/14268043/diff/9001/ly/engraver-init.ly#newcode637
> ly/engraver-init.ly:637: completionFactor = #ly:duration-scale
> We do need to keep issue 1532 fixed, since several people depend on
and expect
> that behavior.
>
> %% Historically, completion_heads_engraver has split integer-scaled
> %% notes into notes with no scaling c1*3 ==> {c1~ c1~ c1~}
> completionFactor = #
> (lambda (dur)
> (let ((scale (ly:duration-scale dur)))
> (if (integer? scale)
> 1
> scale)))
Now that does not change that having to crank out some anonymous
lambda function for some common behavior is a bad idea. At least the
previous default behavior should be available as a stock function, and
one can conceivably teach convert-ly to continue providing the old
inconsistent behavior via an appropriate assignment whenever one of
the completion engravers is being used. Please remember that this old
behavior is _also_ not what "people" expected, or we would not be
having this issue.
The function above provides the old behavior.
You could make the C-code fall-back to the consistent behavior if
someone un-defines 'completionFactor'
factor_ = robust_scm2rational("completionFactor", note_dur.factor());
Then I'll update the docs patch at
http://codereview.appspot.com/14633043
so the known-issue just says "Historically, blah blah... \unset
completionFactor removes this inconsistency."
https://codereview.appspot.com/14268043/
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
