Re: Pianostaff 4-part writing and rests

[Urs Liska]

Am 25. Januar 2015 21:19:26 MEZ, schrieb Keith OHara <address@hidden>:
>Kieren MacMillan <kieren_macmillan <at> sympatico.ca> writes:
>
>> The linked issue (https://code.google.com/p/lilypond/issues/detail?
>id=1228) currently has a
>> status of “abandoned” — well, at least the associated patch does, if
>not 
>the whole issue.
>> 
>> Is there a technical reason why the most up-to-date engraver (e.g.,
>> https://github.com/openlilylib/openlilylib/blob/
>c53380f5ca460d244a017389dc4bcb79a3f04d14/editorial-tools/merge-rests-
>engraver/definition.ily)
>> has not been (or cannot be) rolled into the main Lilypond codebase?
>Or is 
>it technically sound, and now it's
>> only a matter of somebody making an appropriate/official patch and 
>submitting it?
>> 
>
>The latest code looks reasonable.  It needs testing and somebody
>willing
>to potentially modify it to cooperate with the rest of the code.
>It sets merged rests to staff-position 0, so it might interfere in 
>mysterious ways people setting their rests by hand... the automated
>testing reveals things like this.
>
>It is a layer over the existing rest_collision_engraver, so either we
>check that each layer has a distinct-enough job that they won't confuse
>each other, or integrate the two rest-collision engravers into one.
>
>I never looked at this patch because from the issue title 
>"\override RestCollision #'positioning-done =
>#merge-rests-on-positioning" 
>I didn't recognize what problem it was trying to solve, even though I
>am
>often annoyed by that problem.
>I'll try to change the title and add an example of what we want it to
>do.

That would be great. It would be a goid thing if LilyPond would do the right 
thing here without the awkward workarounds.

>_______________________________________________
>lilypond-user mailing list
>address@hidden
>https://lists.gnu.org/mailman/listinfo/lilypond-user