On Tue, Mar 15, 2011 at 10:08 AM, m...@apollinemike.com <m...@apollinemike.com> wrote: > On Mar 15, 2011, at 9:03 AM, Han-Wen Nienhuys wrote: > >> On Mon, Mar 14, 2011 at 9:16 AM, <m...@apollinemike.com> wrote: >> >>> I've sketched this out using your suggestion above (calculating it once and >>> returning the fraction for the called beam) - nevermind my previous >>> question about redoing calculations. A new patch set is on-line. >> >>> I still need to do the math for the longer slopes - I'll have time to do >>> that later today or tomorrow. >>> >>> In the spirit of the one-change-per-push idea, I'd like to push the fix to >>> 1504 first before I push the change to feather-direction. Does this seem >>> like a good idea? >> >> Do you mean: push an earlier version of this patch first? I think >> it's not a good idea, because you would rewrite it directly after >> pushing, cluttering up the history of what is happening. The idea of >> one-change-per-push is that all the individual changes are >> independent. > > No, I mean that changing the feather-dir property from ly:dir to a pair seems > like a different problem than fixing issue 1504. It effectively adds a new > feature to lilypond, and thus seems like it should be the object of its own > patch/push. However, if you think I
Ah right. My proposal was for feather-dir to be used to init feather-fractions (or whatever they're called.) - please do what you think is best, but if you are pushing 2 commits where the 2nd mostly rewrites the 1st, you might as well skip the 1st. I would call this a feature, btw; I don't believe we ever suggested that breaking feathered beams works. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
