there are actually four commits:

there are actually four commits:

commit 1: Create exact-rational? predicate

commit 2: Create completionFactorUnit

commit 3: Change regtests for completion engravers for illustrating issue 3560
(and using completionFactorUnit)

commit 4: Issue 3560: make use of completionFactorUnit in completion engravers

factor out chopping into a base class Completion_engraver_base

Both the Completion_heads_engraver and Completion_rest_engraver have
to make the decision whether to interpret a scale factor on a note
either as actually scaling the note duration itself (similar to
\times/\tuplet) or as a means of specifying an inconvenient length,
like a full bar note in 5/8 time or a multi-measure note (or,
actually, combination of all these).  The completion engravers need to
make an actual decision here.

The previously employed heuristic was that integer scale factors were
interpreted as a multi-measure note while other rational scale
factors implied an actual scaling of the note value.  In the first
case, any durations produced by the completion engravers received a
scale factor of 1, in the second, they inherited the original scale
factor.  The visual note duration needed for filling the measure
depended on the chosen scale factor.

This heuristic led to surprises like issue 1772: the behavior of
issue 1772 was triggered by scale factors like *3/2 but not by *3/1.
Now the heuristic has been dropped, so either scale factor will lead
to the observed behavior.

Since both behaviours are required (see issue 1532), introduce
a means to control the decision explicitly, defaulting to the
existing behaviour.  The device chosen in this patch is
completionFactorUnit.

[benko.pal, 2013-10-13 21:07:29]

new regtest annotated (and changed) a bit

[Keith, 2013-10-25 07:04:55]

None of the examples show \set completionFactorUnit = n/m  actually helping.  Is
there an example where this property is more useful than a boolean switch?

By contrast, the earlier patch <http://codereview.appspot.com/14633043> using
completionLongestScaled to divide long- versus short notes, made the examples in
the bug-reports work by default, and included documentation.

Either this patch or the earlier one could be augmented by allowing users to set
'completionFactor' to specify the output scale-factor that the engraver should
use for 'long' notes, for the case Pál brought up \scaleDurations 2/3 { a1.*9 }

https://codereview.appspot.com/14640043/diff/3001/input/regression/completion...
File input/regression/completion-rest.ly (right):

https://codereview.appspot.com/14640043/diff/3001/input/regression/completion...
input/regression/completion-rest.ly:9: just scale the total duration taken.
This claims that {r1*2}
would be split into {r2*2 | r2*2}
but that is not what the code does.

https://codereview.appspot.com/14640043/diff/3001/input/regression/completion...
input/regression/completion-rest.ly:25: r4 ^"r4" r8*4 ^"r8*4" r8*8 ^"r8*8"
The un-split r8*4 makes the test hard to interpret.

https://codereview.appspot.com/14640043/diff/3001/scm/define-context-properti...
File scm/define-context-properties.scm (right):

https://codereview.appspot.com/14640043/diff/3001/scm/define-context-properti...
scm/define-context-properties.scm:238: rather than scaled notes.
Does this actually work?

\scaleDurations 2/1 {
  \set completionFactorUnit = 2/1
  g4 a2 b4 }

It seems that the engraver would see { g4*2 a2*2 b4*2 }
and split a1*2 as a 'long' note into { g4*2 a2~ | a2 b4*2 }

Maybe only integer-greater-than-one multiples should count?

https://codereview.appspot.com/14640043/diff/3001/scm/define-context-properti...
scm/define-context-properties.scm:243: interpreting whole measure multiples as
long notes.
I do not see why this is true.  There can be tuplets that scale music by *3/4 in
3/4 time.
{\time 3/4
\tuplet 4/3 {c4 d e f} \tuplet 4/3 {g2 a1 b2} \tuplet 2/3 {c4 c,}}

[dak, 2013-10-25 07:35:31]

On 2013/10/25 07:04:55, Keith wrote:
> None of the examples show \set completionFactorUnit = n/m  actually helping. 
Is
> there an example where this property is more useful than a boolean switch?

No, because completionFactorUnit is only used for determining the
position of a boolean switch.  You can always throw this switch
yourself since the engraver only works with a single duration at a
single point of time.

> By contrast, the earlier patch <http://codereview.appspot.com/14633043> using
> completionLongestScaled to divide long- versus short notes, made the examples
in
> the bug-reports work by default, and included documentation.

completionLongestScaled does not work satisfactorily with
\scaleDurations, the main reason for having this patch in the first
place.  It's also incompatible to the previous behavior.

> Either this patch or the earlier one could be augmented by allowing
> users to set 'completionFactor' to specify the output scale-factor
> that the engraver should use for 'long' notes, for the case Pál
> brought up \scaleDurations 2/3 { a1.*9 }

Sure, but that's leaving the "binary switch" area and is an orthogonal
advancement.  You still need to decide how to throw the switch.

>
https://codereview.appspot.com/14640043/diff/3001/input/regression/completion...
> input/regression/completion-rest.ly:25: r4 ^"r4" r8*4 ^"r8*4" r8*8 ^"r8*8"
> The un-split r8*4 makes the test hard to interpret.

The un-split r8*4 makes the whole behavior of Completion_*_engraver
hard to interpret.  That was my point for the very first patch
_always_ maintaining the current scale factor.  It is the only
behavior where the output of Completion_*_engraver is _consistent_
between notes crossing a completion boundary and those that don't.

The point of a regression test is to demonstrate that the behavior
works as designed.  I consider it a poor design decision to treat some
notes differently as others, but _that's_ _what_ _people_ _want_.
We'd have been finished a month ago if they didn't.  And so we should
document the consequences of what they want.