Re: renaming vertical spacing inside systems props
On 2010-11-09 00:54, Trevor Daniels wrote: Mark Polesky wrote Monday, November 08, 2010 7:14 PM Keith E OHara wrote: We will use this in context that makes that first qualifier almost redundant : \override Context.StaffGrouper #'withingroup-staff-staff-spacing This is an excellent point, and in response I'd like to propose one more option -- just remove the withingroup prefix altogether: \override StaffGrouper #'staff-staff-spacing \override StaffGrouper #'staffgroup-staff-spacing Thoughts? LGTM (As I've said before, I admire your persistence :) +1. Cheers, Alexander ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: renaming vertical spacing inside systems props
Mark Polesky wrote Monday, November 08, 2010 1:24 AM Instead of these two: withingroup-staff-staff-spacing staffgroup-staff-spacing Let's stay with these. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: renaming vertical spacing inside systems props
2010/11/8 Mark Polesky markpole...@yahoo.com: Instead of these two: withingroup-staff-staff-spacing staffgroup-staff-spacing While these aren't perfect, i'd say that within-group-staff-staff-spacing below-group-staff-staff-spacing inside-group-staff-staff-spacing outside-group-staff-staff-spacing are worse. Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: renaming vertical spacing inside systems props
Keith E OHara wrote: We will use this in context that makes that first qualifier almost redundant : \override Context.StaffGrouper #'withingroup-staff-staff-spacing This is an excellent point, and in response I'd like to propose one more option -- just remove the withingroup prefix altogether: \override StaffGrouper #'staff-staff-spacing \override StaffGrouper #'staffgroup-staff-spacing Yes, I know we already have a 'staff-staff-spacing for the VerticalAxisGroup grob, but there's no law saying we can't have a different property with the same name for the StaffGrouper grob. We already do that in several other cases, for example: \override Beam #'details = ... \override Stem #'details = ... Similarly, I think the two 'staff-staff-spacing properties would be intuitive and easy enough to keep separate, mentally: % space between consecutive staves in a system \override VerticalAxisGroup #'staff-staff-spacing % space between consecutive staves in a staff-group \override StaffGrouper #'staff-staff-spacing The property descriptions could have a brief mention to dispel any confusion, and then we won't need any awkward and long withingroup prefix. And best of all, the name is consistent with the item1-item2-spacing format. I think it's elegant. Thoughts? - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: renaming vertical spacing inside systems props
Mark Polesky markpole...@yahoo.com writes: % space between consecutive staves in a system \override VerticalAxisGroup #'staff-staff-spacing % space between consecutive staves in a staff-group \override StaffGrouper #'staff-staff-spacing The property descriptions could have a brief mention to dispel any confusion, and then we won't need any awkward and long withingroup prefix. And best of all, the name is consistent with the item1-item2-spacing format. I think it's elegant. Thoughts? Those spacing parameters are not supposed to be set in the \header? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: renaming vertical spacing inside systems props
On 11/8/10 1:14 PM, Mark Polesky markpole...@yahoo.com wrote: Keith E OHara wrote: We will use this in context that makes that first qualifier almost redundant : \override Context.StaffGrouper #'withingroup-staff-staff-spacing This is an excellent point, and in response I'd like to propose one more option -- just remove the withingroup prefix altogether: \override StaffGrouper #'staff-staff-spacing \override StaffGrouper #'staffgroup-staff-spacing I like it. staff-staff spacing is the spacing between two staves in the staff group; staffgroup-staff-spacing is the spacing between the group and the next staff. Intuitive and consistent. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: renaming vertical spacing inside systems props
Mark Polesky wrote Monday, November 08, 2010 7:14 PM Keith E OHara wrote: We will use this in context that makes that first qualifier almost redundant : \override Context.StaffGrouper #'withingroup-staff-staff-spacing This is an excellent point, and in response I'd like to propose one more option -- just remove the withingroup prefix altogether: \override StaffGrouper #'staff-staff-spacing \override StaffGrouper #'staffgroup-staff-spacing Thoughts? LGTM (As I've said before, I admire your persistence :) Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: renaming vertical spacing inside systems props
On Mon, 08 Nov 2010 11:14:11 -0800, Mark Polesky markpole...@yahoo.com wrote: Similarly, I think the two 'staff-staff-spacing properties would be intuitive and easy enough to keep separate, mentally: % space between consecutive staves in a system \override VerticalAxisGroup #'staff-staff-spacing % space between consecutive staves in a staff-group \override StaffGrouper #'staff-staff-spacing Thoughts? From the users' point of view, your suggestion is a clear improvement. The two properties have the same form and the same function, so you would spare us the trouble of remembering that they are the same. But before folding two property names together, you should search for uses of the old names, to check whether the code ever assumes that any object with a 'between-staff-spacing' must be StaffGrouper, or if it ever assumes that anything with a 'next-staff-spacing' must be VerticalAxisGroup. After a git grep for the two old names, only the function append_system() in page-layout-problem.cc looked like it might act differently if the names are merged. -- Keith ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: renaming vertical spacing inside systems props
On 11/8/10 9:34 PM, Keith E OHara k-ohara5...@oco.net wrote: On Mon, 08 Nov 2010 11:14:11 -0800, Mark Polesky markpole...@yahoo.com wrote: Similarly, I think the two 'staff-staff-spacing properties would be intuitive and easy enough to keep separate, mentally: % space between consecutive staves in a system \override VerticalAxisGroup #'staff-staff-spacing % space between consecutive staves in a staff-group \override StaffGrouper #'staff-staff-spacing Thoughts? From the users' point of view, your suggestion is a clear improvement. The two properties have the same form and the same function, so you would spare us the trouble of remembering that they are the same. But before folding two property names together, you should search for uses of the old names, to check whether the code ever assumes that any object with a 'between-staff-spacing' must be StaffGrouper, or if it ever assumes that anything with a 'next-staff-spacing' must be VerticalAxisGroup. After a git grep for the two old names, only the function append_system() in page-layout-problem.cc looked like it might act differently if the names are merged. I don't think it matters if the names are merged. This is because the property name is specific to a grob. TabNoteHead 'details is not the same thing as Beam 'details, even though the name is the same. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: renaming vertical spacing inside systems props
\override StaffGrouper #'staff-staff-spacing \override StaffGrouper #'staffgroup-staff-spacing LGTM (As I've said before, I admire your persistence :) If David's comment isn't a valid concern, this is fine with me too. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: renaming vertical spacing inside systems props
Renaming proposals, round 4:
CURRENT NAME PROPOSED NAME
-
next-staff staff-staff
default-next-staff default-staff-staff
inter-staffnonstaff-relatedstaff
inter-loose-line nonstaff-nonstaff
non-affinity nonstaff-unrelatedstaff
between-staff withingroup-staff-staff
after-last-staff staffgroup-staff
This is fine with me.
And lastly, I still think reference/opposite is better than
related/unrelated:
nonstaff-referencestaff
nonstaff-oppositestaff
Well, `related/unrelated' refers to the functionality, and `reference'
too. However, `opposite' refers to a visual concept which IMHO
doesn't harmonize well with the other terms.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: renaming vertical spacing inside systems props
Keith E OHara wrote Sunday, November 07, 2010 2:54 AM On Sat, 06 Nov 2010 18:20:08 -0700, lilypond-devel-requ...@gnu.org wrote: [...] And lastly, I still think reference/opposite is better than related/unrelated: nonstaff-referencestaff nonstaff-oppositestaff But I won't protest. Any last thoughts/votes, or should I go ahead with the proposals listed above I had imagined you would simultaneously change staff-affinity (UP / DOWN / CENTER) toreference-direction (UP / DOWN / CENTER) so we can remember that this direction tells us which staff is which between referencestaff and oppositestaff. We might convince Mr Daniels that this is good enough reason to support your (unabbreviated) preference, or he might come up with an even better suggestion for the variable that chooses which direction is the 'related' direction. My rationale is to choose words that stand-alone and carry a clear indication of both the underlying concept and the relationship to other properties. I like staff-affinity because it means an attraction to or relationship with a staff. Sounds just right. reference-direction is OK too, but suffers from not indicating staff as the relevant object. referencestaff in itself satisfies my criteria, and I'd be happy with that, but I don't like oppositestaff. It has no meaning in itself, as there is no indication in its name what it is opposite to. You have to remember it is it is one of a related pair and its partner is called referencestaff. OTOH relatedstaff/unrelatedstaff both stand alone with clear meanings, and with a clear association with staff-affinity, as one of the meanings of affinity is having a relationship. All that said, I'm not going to protest against any of the recent proposals; they're all an improvement over existing wording. All I have is a preference, nothing stronger. Others have other preferences, and, having stated my case, I'm happy to go along with the majority view. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: renaming vertical spacing inside systems props
On Sat, 06 Nov 2010 20:08:06 -0700, Mark Polesky markpole...@yahoo.com wrote: Keith E OHara wrote: I had imagined you would simultaneously change staff-affinity (UP / DOWN / CENTER) toreference-direction (UP / DOWN / CENTER) so we can remember that this direction tells us which staff is which between referencestaff and oppositestaff. I think staff-affinity is more informative than reference-direction. Cool. It does make some sense that staff-affinity tells you which staff is the relatedstaff, because Affinity and Relationship can be synonyms. nonstaff-unrelatedstaff-spacing also determines the space between an UP nonstaff and a DOWN nonstaff (if there is no CENTER nonstaff between them)... I *think* that's just a case of stretching to prevent collisions. Does the same happen when all the 'stretchability and 'padding keys are set to 0? If yes, please post a minimal example. I think so, but with so many rods and springs in there, I might have missed one. If your mind is still on this tomorrow, I'll post a minimal example in relation to issue 1309 (one of the troika of lyrics issues). My proposed changes to the spacing defaults make the problem in 1309 slightly worse, and tomorrow I'll post why and see if that opens the door to a satisfactory workaround. - Keith ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: renaming vertical spacing inside systems props
Trevor Daniels wrote: relatedstaff/unrelatedstaff Okay, I think enough votes are in to finalize the most recent proposal: http://lists.gnu.org/archive/html/lilypond-devel/2010-11/msg00137.html So relatedstaff/unrelatedstaff it will be. I'll have more time to start making this change later today. Thanks for everyone's input. - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: renaming vertical spacing inside systems props
Mark Polesky markpole...@yahoo.com writes: Mark Polesky wrote: Okay, I think enough votes are in to finalize the most recent proposal: http://lists.gnu.org/archive/html/lilypond-devel/2010-11/msg00137.html I almost forgot... Can we have one last vote among these two choices? 1) within-group-staff-staff-spacing 2) withingroup-staff-staff-spacing Abstain. Would not want to be on record in support of either... -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: renaming vertical spacing inside systems props
Mark Polesky wrote Sunday, November 07, 2010 4:40 PM Mark Polesky wrote: Okay, I think enough votes are in to finalize the most recent proposal: http://lists.gnu.org/archive/html/lilypond-devel/2010-11/msg00137.html I almost forgot... Can we have one last vote among these two choices? 1) within-group-staff-staff-spacing 2) withingroup-staff-staff-spacing In this thread, there are at least 11 people with a vested interest (I added Joe even though he's been silent). Anyone else wanting to vote, feel free to add your name to this list. Please enter your preference among the 2 choices above. I've already entered mine. Carl: David: James: Jan: Jean-Charles: Joe: Keith: Mark: 1 Trevor: 2 Valentin: 1* Werner: 2 *was 2, then changed it to 1? Which one is it? Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: renaming vertical spacing inside systems props
On Sun, 07 Nov 2010 07:57:33 -0800, Mark Polesky wrote: Can we have one last vote among these two choices? 1) within-group-staff-staff-spacing 2) withingroup-staff-staff-spacing Keith: either Both are usable. We will use this in context that makes that first qualifier almost redundant : \override Context.StaffGrouper #'withingroup-staff-staff-spacing ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: renaming vertical spacing inside systems props
1) within-group-staff-staff-spacing 2) withingroup-staff-staff-spacing Werner: 2 I think option 2 is more consistent, but I don't really care. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: renaming vertical spacing inside systems props
Oops, forgot to actually *add* Joe to this! * * * * * * * * * * * * Mark Polesky wrote: Okay, I think enough votes are in to finalize the most recent proposal: http://lists.gnu.org/archive/html/lilypond-devel/2010-11/msg00137.html I almost forgot... Can we have one last vote among these two choices? 1) within-group-staff-staff-spacing 2) withingroup-staff-staff-spacing In this thread, there are at least 11 people with a vested interest (I added Joe even though he's been silent). Anyone else wanting to vote, feel free to add your name to this list. Please enter your preference among the 2 choices above. I've already entered mine. Carl: David: James: Jan: Jean-Charles: Joe: Keith: Mark: 1 Trevor: Valentin: Werner: Thanks - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: renaming vertical spacing inside systems props
On 11/7/10 9:52 AM, Mark Polesky markpole...@yahoo.com wrote: Mark Polesky wrote: Okay, I think enough votes are in to finalize the most recent proposal: http://lists.gnu.org/archive/html/lilypond-devel/2010-11/msg00137.html I almost forgot... Can we have one last vote among these two choices? 1) within-group-staff-staff-spacing 2) withingroup-staff-staff-spacing In this thread, there are at least 11 people with a vested interest (I added Joe even though he's been silent). Anyone else wanting to vote, feel free to add your name to this list. Please enter your preference among the 2 choices above. I've already entered mine. Carl: 2, but not too strongly David: James: Jan: Jean-Charles: Keith: Mark: 1 Trevor: Valentin: Werner: ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: renaming vertical spacing inside systems props
On Sun, Nov 7, 2010 at 4:52 PM, Mark Polesky markpole...@yahoo.com wrote: Carl: David: James: Jan: Jean-Charles: Keith: Mark: 1 Trevor: Valentin: 1 Werner: 2 This is fun, kinda :-) Cheers, Valentin. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: renaming vertical spacing inside systems props
On Sun, Nov 7, 2010 at 5:40 PM, Mark Polesky markpole...@yahoo.com wrote: Valentin: 1* *was 2, then changed it to 1? Which one is it? Er, is it the same vote we're talking about? I voted 2 in the other thread about the 'space alist: 2) initial-distanceminimum-distance But I thought here we were talking only about within-group vs withingroup, which is where I like the #1 option better. (Of course, things like this could be made a lot simpler if we had a Wiki somewhere... but we don't, do we? ;) Cheers, Valentin. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: renaming vertical spacing inside systems props
You guys are going to *hate* me for doing this, but I just thought of a way to keep the StaffGrouper grobs consistent with each other. Instead of these two: withingroup-staff-staff-spacing staffgroup-staff-spacing we could have these: within-group-staff-staff-spacing below-group-staff-staff-spacing (or after-group-...) or these: inside-group-staff-staff-spacing outside-group-staff-staff-spacing Hopefully the lot of you will either 1) love this, 2) hate this, or 3) stop caring! Otherwise I guess we'll keep on voting. I expressly tried to do this in a way to keep voting to a minimum. Obviously I completely failed. Thoughts? - Mark p.s. withingroup was in the lead... ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: renaming vertical spacing inside systems props
On 11/7/10 7:24 PM, Mark Polesky markpole...@yahoo.com wrote: You guys are going to *hate* me for doing this, but I just thought of a way to keep the StaffGrouper grobs consistent with each other. Instead of these two: withingroup-staff-staff-spacing staffgroup-staff-spacing Keep this one. It's the space between the group and the next staff. Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: renaming vertical spacing inside systems props
Okay, it looks like we're converging here... Renaming proposals, round 4: CURRENT NAME PROPOSED NAME - next-staff staff-staff default-next-staff default-staff-staff inter-staffnonstaff-relatedstaff inter-loose-line nonstaff-nonstaff non-affinity nonstaff-unrelatedstaff between-staff withingroup-staff-staff after-last-staff staffgroup-staff It seems that no one here is opposed to the odd-looking compound words (withingroup, relatedstaff etc.), which surprises me a little. They remind me of the common mistake of reading manslaughter as man's laughter... Anyway, if nobody minds these, I guess I don't mind either. And lastly, I still think reference/opposite is better than related/unrelated: nonstaff-referencestaff nonstaff-oppositestaff But I won't protest. Any last thoughts/votes, or should I go ahead with the proposals listed above? - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: renaming vertical spacing inside systems props
On 11/6/10 7:17 PM, Mark Polesky markpole...@yahoo.com wrote:
Okay, it looks like we're converging here...
Renaming proposals, round 4:
CURRENT NAME PROPOSED NAME
-
next-staff staff-staff
default-next-staff default-staff-staff
inter-staffnonstaff-relatedstaff
inter-loose-line nonstaff-nonstaff
non-affinity nonstaff-unrelatedstaff
between-staff withingroup-staff-staff
after-last-staff staffgroup-staff
It seems that no one here is opposed to the odd-looking
compound words (withingroup, relatedstaff etc.), which
surprises me a little. They remind me of the common
mistake of reading manslaughter as man's laughter...
Anyway, if nobody minds these, I guess I don't mind either.
I don't particularly like them, but I can't come up with a better
alternative, and they're much better than the previous, IMO.
And lastly, I still think reference/opposite is better than
related/unrelated:
nonstaff-referencestaff
nonstaff-oppositestaff
I'd be fine with either reference or related.
Whatever you want is fine with me.
Thanks,
Carl
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: renaming vertical spacing inside systems props
On Sat, 06 Nov 2010 18:20:08 -0700, lilypond-devel-requ...@gnu.org wrote: Renaming proposals, round 4: CURRENT NAME PROPOSED NAME - next-staff staff-staff default-next-staff default-staff-staff inter-staffnonstaff-relatedstaff inter-loose-line nonstaff-nonstaff non-affinity nonstaff-unrelatedstaff between-staff withingroup-staff-staff after-last-staff staffgroup-staff [...] And lastly, I still think reference/opposite is better than related/unrelated: nonstaff-referencestaff nonstaff-oppositestaff But I won't protest. Any last thoughts/votes, or should I go ahead with the proposals listed above Mark, I had imagined you would simultaneously change staff-affinity (UP / DOWN / CENTER) toreference-direction (UP / DOWN / CENTER) so we can remember that this direction tells us which staff is which between referencestaff and oppositestaff. We might convince Mr Daniels that this is good enough reason to support your (unabbreviated) preference, or he might come up with an even better suggestion for the variable that chooses which direction is the 'related' direction. Everything else looks consistent. The closest I could find to a flaw was that nonstaff-unrelatedstaff-spacing also determines the space between an UP nonstaff and a DOWN nonstaff (if there is no CENTER nonstaff between them) but I honestly prefer understandable names that describe 99% of the use cases, than theoretically perfect ones. -- Keith ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: renaming vertical spacing inside systems props
Keith E OHara wrote: I had imagined you would simultaneously change staff-affinity (UP / DOWN / CENTER) toreference-direction (UP / DOWN / CENTER) so we can remember that this direction tells us which staff is which between referencestaff and oppositestaff. I think staff-affinity is more informative than reference-direction. The closest I could find to a flaw was that nonstaff-unrelatedstaff-spacing also determines the space between an UP nonstaff and a DOWN nonstaff (if there is no CENTER nonstaff between them)... I *think* that's just a case of stretching to prevent collisions. Does the same happen when all the 'stretchability and 'padding keys are set to 0? If yes, please post a minimal example. - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: renaming vertical spacing inside systems props
Valentin Villenave wrote Thursday, November 04, 2010 12:10 AM
On Thu, Nov 4, 2010 at 12:58 AM, Trevor Daniels t.dani...@treda.co.uk wrote:
Renaming proposals, round 3:
CURRENT NAME PROPOSED NAMETD's PREFERENCE
----
next-staff staff-staff
default-next-staff default-staff-staff
inter-staffnonstaff-refstaffnonstaff-relatedstaff
inter-loose-line nonstaff-nonstaff
non-affinity nonstaff-oppstaffnonstaff-unrelatedstaff
between-staff within-group-staff-staff withingroup-staff-staff
after-last-staff group-staff staffgroup-staff
IMO that's the best proposal I've seen so far.
:)
So, I don't know what this TD stands for (Tropical Depression?
Treasury Department?), but it has my vote :-)
It's on the back of my car. Many people think it stands
for Turbo Diesel, but they're wrong.
Cheers,
Valentin.
Turbo, aka Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: renaming vertical spacing inside systems props
James wrote: Unless we really explain this properly in the docs what this term actually means, it really does put a lot of people off (i.e. me). There are two rather large doc patches already under construction (and being discussed) to address this: http://codereview.appspot.com/2758042/ http://codereview.appspot.com/2642043/ #2642043 is the one related to this particular thread. If you can't compile the patches yourself (that took me a while to learn), you can still click on the View links (in the Side-by-side diffs column) to see proposed changes to the documentation source. Hope this helps. - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: renaming vertical spacing inside systems props
2010/11/3 Mark Polesky markpole...@yahoo.com Actually, now I really like refstaff/oppstaff: nonstaff-refstaff-spacing nonstaff-nonstaff-spacing nonstaff-oppstaff-spacing Somehow I don't like it. It feels not descriptive enough imo, at least for non-native english speakers: users would ponder WTH this ref and opp is all about?. Jan ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: renaming vertical spacing inside systems props
On Thu, Nov 4, 2010 at 12:58 AM, Trevor Daniels t.dani...@treda.co.uk wrote: Renaming proposals, round 3: CURRENT NAME PROPOSED NAME TD's PREFERENCE - --- next-staff staff-staff default-next-staff default-staff-staff inter-staff nonstaff-refstaff nonstaff-relatedstaff inter-loose-line nonstaff-nonstaff non-affinity nonstaff-oppstaff nonstaff-unrelatedstaff between-staff within-group-staff-staff withingroup-staff-staff after-last-staff group-staff staffgroup-staff IMO that's the best proposal I've seen so far. So, I don't know what this TD stands for (Tropical Depression? Treasury Department?), but it has my vote :-) Cheers, Valentin. (By the way, I can't help but notice that TD's almost looks like Ts'o -- have you ever thought that there may be a Linux developer within you? :-) http://en.wikipedia.org/wiki/Theodore_Ts%27o ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: renaming vertical spacing inside systems props
Carl Sorensen wrote Wednesday, November 03, 2010 11:00 PM On 11/3/10 2:49 PM, Mark Polesky markpole...@yahoo.com wrote: Trevor wrote: I wonder if affinity/nonaffinity are optimal. Are they better than relatedstaff/unrelatedstaff? Or target/opposite, reference/opposite, refstaff/oppstaff? Actually, now I really like refstaff/oppstaff: ref and opp are abbreviations and not good for non-native-english speakers. +1 Abbreviations are bad, bad. nonstaff-associatedstaff-spacing nonstaff-nonstaff-spacing nonstaff-freestaff-spacing or nonstaff-isolatedstaff-spacing Looking at a thesaurus, I have some more ideas: nonstaff-relatedstaff vs. nonstaff-unrelatedstaff That was my original suggestion :) nonstaff-linkedstaff vs. nonstaff-separatestaff nonstaff-attachedstaff vs. nonstaff-detachedstaff nonstaff-affixedstaff vs. nonstaff-releasedstaff nonstaff-alliedstaff vs. nonstaff-foreignstaff nonstaff-alliedstaff vs. nonstaff-disjoinedstaff I still prefer nonstaff-relatedstaff/nonstaff-unrelatedstaff How do you feel about staffgrouped-staff-staff-spacing ? If we're going with this idea, I'd prefer groupedstaff-staff-staff-spacing since it's better english than staffgrouped IMO. I could live with this, although groupedstaves-staff-staff-spacing is even clearer. It's the same length as within-group-staff-staff-spacing but it has one less hyphen, which for some reason I consider an advantage. Although I might prefer within-group anyway. Now, if we do use within-group-staff-staff-spacing Maybe it's withingroup-staff-staff-spacing. This looks the best so far to me. I thought we might as well shorten staffgroup-staff-spacing to group-staff-spacing . What do you think? I prefer staffgroup-staff spacing, since it's a staffgroup object, not a group object, that we're trying to space. +1 Renaming proposals, round 3: CURRENT NAME PROPOSED NAMETD's PREFERENCE ---- next-staff staff-staff default-next-staff default-staff-staff inter-staffnonstaff-refstaffnonstaff-relatedstaff inter-loose-line nonstaff-nonstaff non-affinity nonstaff-oppstaff nonstaff-unrelatedstaff between-staff within-group-staff-staff withingroup-staff-staff after-last-staff group-staff staffgroup-staff ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: renaming vertical spacing inside systems props
On 11/3/10 2:49 PM, Mark Polesky markpole...@yahoo.com wrote:
Note that item2 is not necessarily below item1; for
example, 'loose-staff-spacing will measure upwards from
the loose line if 'staff-affinity = #UP.
Trevor wrote:
I wonder if affinity/nonaffinity are optimal. Are they
better than relatedstaff/unrelatedstaff?
Or target/opposite, reference/opposite, refstaff/oppstaff?
Actually, now I really like refstaff/oppstaff:
nonstaff-refstaff-spacing
nonstaff-nonstaff-spacing
nonstaff-oppstaff-spacing
ref and opp are abbreviations and not good for non-native-english speakers.
nonstaff-associatedstaff-spacing
nonstaff-nonstaff-spacing
nonstaff-freestaff-spacing or nonstaff-isolatedstaff-spacing
Where one staff is associated with the nonstaff and the other staff is free?
Looking at a thesaurus, I have some more ideas:
nonstaff-relatedstaff vs. nonstaff-unrelatedstaff
nonstaff-linkedstaff vs. nonstaff-separatestaff
nonstaff-attachedstaff vs. nonstaff-detachedstaff
nonstaff-affixedstaff vs. nonstaff-releasedstaff
nonstaff-alliedstaff vs. nonstaff-foreignstaff
nonstaff-alliedstaff vs. nonstaff-disjoinedstaff
So my preference is for [groupedstaff-groupedstaff].
Trevor, after some consideration, I'm afraid I'm not so much
in favor of groupedstaff-groupedstaff (or it's shorter
cousin). They too strongly suggest the possibility of this:
[last staff of group] - [first staff of next group]
Carl Sorensen wrote:
I just thought of a c': within-group-staff-staff. Longer,
but might explain it more clearly.
It would be the longest, but I like the clarity. How do you
feel about
staffgrouped-staff-staff-spacing ?
If we're going with this idea, I'd prefer
groupedstaff-staff-staff-spacing
since it's better english than staffgrouped IMO.
It's the same length as
within-group-staff-staff-spacing
but it has one less hyphen, which for some reason I consider
an advantage. Although I might prefer within-group anyway.
Now, if we do use
within-group-staff-staff-spacing
Maybe it's withingroup-staff-staff-spacing.
This is an exception, so I'm not sure exactly how to best resolve it.
I thought we might as well shorten
staffgroup-staff-spacing
to
group-staff-spacing .
What do you think?
I prefer staffgroup-staff spacing, since it's a staffgroup object, not a
group object, that we're trying to space.
The length of the descriptor is not that important to me -- I don't type it
very much. Having it be clear is more important than having it be short.
Thanks,
Carl
* * * * * * * * * * * * * * *
Renaming proposals, round 3:
CURRENT NAME PROPOSED NAME
-
next-staff staff-staff
default-next-staff default-staff-staff
inter-staffnonstaff-refstaff
inter-loose-line nonstaff-nonstaff
non-affinity nonstaff-oppstaff
between-staff within-group-staff-staff
after-last-staff group-staff
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: renaming vertical spacing inside systems props
(trying to make this as painless as possible...) Renaming proposals, round 2: CURRENT NAME PROPOSED NAME - next-staff staff-staff default-next-staff default-staff-staff inter-staffnonstaff-staff inter-loose-line nonstaff-nonstaff non-affinity nonstaff-nonaffinity between-staff (see below) after-last-staff staffgroup-staff * * * * * * * * * * * * * * * Notes: 1) nonstaff beat out loose by a large margin. Sorry Carl! (: 2) all the ideas for between-staff so far: * names consistent with the item1-item2 format a) groupstaff-groupstaff (Trevor) b) groupedstaff-groupedstaff (Trevor) c) grouped-staff-staff (Mark) * shorter names d) inside-staffgroup (Mark) e) grouped-staff (Carl) f) grouped-staves (Carl) Should we vote on this? I'd vote for either c or f. Here are some of my observations. First group, with consistent names: The problem with a and b is that they might suggest between the last staff of one staffgroup and the first staff of the next staffgroup. The problem with c is that grouped-staff-staff might be misread as groupedstaff-staff. Personally, I think this is a smaller problem than the others. Second group, with shorter names: The problem with d is that it might suggest that non-staff lines are involved, instead of just staves. The problem with e is that it might suggest that it could apply after the last staff of a staffgroup. I think that f has none of these problems. Thanks for your input. - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: renaming vertical spacing inside systems props
On 11/2/10 2:56 PM, Mark Polesky markpole...@yahoo.com wrote:
(trying to make this as painless as possible...)
Renaming proposals, round 2:
CURRENT NAME PROPOSED NAME
-
next-staff staff-staff
default-next-staff default-staff-staff
inter-staffnonstaff-staff
How about nonstaff-affinity (to match the nonstaff-nonaffinity)?
inter-loose-line nonstaff-nonstaff
non-affinity nonstaff-nonaffinity
between-staff (see below)
after-last-staff staffgroup-staff
* * * * * * * * * * * * * * *
Notes:
1) nonstaff beat out loose by a large margin.
Sorry Carl! (:
I was one of those votes at the end!
2) all the ideas for between-staff so far:
* names consistent with the item1-item2 format
a) groupstaff-groupstaff (Trevor)
b) groupedstaff-groupedstaff (Trevor)
c) grouped-staff-staff (Mark)
* shorter names
d) inside-staffgroup (Mark)
e) grouped-staff (Carl)
f) grouped-staves (Carl)
First, you'll hear my comment as a design instructor who is trying to teach
students how to work in teams to select the best design concepts: Never
associate an idea with the person who thought of it -- that can put the
focus on *who* is right instead of *what* is right.
Second, I liked your thoughts on the rationales behind the various naming
systems. Given all of the thoughts you so eloquently expressed, my final
choice comes down to either a) or f). As far as a) is concerned, I think
that users can understand the difference between StaffGrouper and
groupstaff, and the top-bottom consistency is admirable. I could easily
support a.
However, given that we have a StaffGrouper property, I think that
grouped-staves is a good name, even though it doesn't match the pattern. SO
I could also support f.
As far as I'm concerned, you can choose either one and I'll be fine. (I'd
also be fine with c).
I just thought of a c': within-group-staff-staff. Longer, but might explain
it more clearly.
Thanks,
Carl
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: renaming vertical spacing inside systems props
Mark Polesky wrote Tuesday, November 02, 2010 8:56 PM Renaming proposals, round 2: CURRENT NAME PROPOSED NAME - next-staff staff-staff default-next-staff default-staff-staff inter-staffnonstaff-staff I'd go with Carl's suggestion of nonstaff-affinity here. But is this really strictly top-down directional, or does this apply even when the nonstaff is below the staff? (The usual placement for lyrics is below the staff to which they have an affinity, and there is no staff-nonstaff.) I wonder if affinity/nonaffinity are optimal. Are they better than relatedstaff/unrelatedstaff? inter-loose-line nonstaff-nonstaff non-affinity nonstaff-nonaffinity between-staff (see below) after-last-staff staffgroup-staff * * * * * * * * * * * * * * * Notes: 1) nonstaff beat out loose by a large margin. Sorry Carl! (: 2) all the ideas for between-staff so far: * names consistent with the item1-item2 format a) groupstaff-groupstaff (Trevor) b) groupedstaff-groupedstaff (Trevor) c) grouped-staff-staff (Mark) * shorter names d) inside-staffgroup (Mark) e) grouped-staff (Carl) f) grouped-staves (Carl) Should we vote on this? I'd vote for either c or f. Here are some of my observations. I think (c) could easily be interpreted to mean groupedstaff-ungroupedstaff, since ungroupedstaff is the meaning of staff elsewhere. So my preference is for (b). It is long, but it's meaning is clearest, especially as staffgroup exists to help dispel confusion. I would also be happy with (a) (so no surprises there :) If we go for the shorter names I prefer (f). Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: renaming vertical spacing inside systems props
Le 01/11/2010 00:09, Carl Sorensen disait : On 10/31/10 3:00 PM, Keith E OHarak-ohara5...@oco.net wrote: On Fri, 29 Oct 2010 21:04:06 -0700,lilypond-devel-requ...@gnu.org wrote: Mark Polesky wrote Friday, October 29, 2010 11:27 PM I've thought about it, and I think I slightly favor the term loose line over non-staff line [...] Also loose-staff-spacing sounds too much like something that gives staves a loose spacing (rather than a tight spacing) to anyone coming to this for the first time. Thanks for doing this, Mark. It seems you want a one-word _noun_, to refer to either a line of lyrics and a line of dynamics, in the limited context of its placement relative to the neighboring staffs, and similar lines of lyrics/dynamics. Simply 'line' ? I think 'line' could easily be confused with a staff line. I think perhaps 'nonstaff' would be better. So we could have nonstaff-staff-spacing Remember the user cannot see why they are called loose -- maybe indirectly in the way these lines are placed in a second step after the staff lines, but the docs about that second step do not use the word 'loose'. But they might, once the terminology is finalized. The visible difference from regular staffs is that lyrics/dynamics have an affinity. They are attached, in their spacing behavior, to one a parent staff, or centered between two parent staffs, and negotiate with their siblings for space. This is a nice statement! Thanks! May I suggest my point of view, which includes some taste of translation: I need in my score at least four containers: one line containing the staff (grid with a certain number of strokes), one line containing the dynamics, one line containing the lyrics, and one line containing the figured bass. The last three are not loose since their material is synchronized with the information displayed on the staff. At this point, everybody knows what a staff is, and what are the others: an alignment of characters, or at least not a staff. Then I would prefer the dichotomy staff vs. non-staff (being labeled nonstaff in grobs or properties). This was the thought of the day. Cheers, Jean-Charles ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: renaming vertical spacing inside systems props
On Fri, 29 Oct 2010 21:04:06 -0700, lilypond-devel-requ...@gnu.org wrote: Mark Polesky wrote Friday, October 29, 2010 11:27 PM I've thought about it, and I think I slightly favor the term loose line over non-staff line [...] Also loose-staff-spacing sounds too much like something that gives staves a loose spacing (rather than a tight spacing) to anyone coming to this for the first time. Thanks for doing this, Mark. It seems you want a one-word _noun_, to refer to either a line of lyrics and a line of dynamics, in the limited context of its placement relative to the neighboring staffs, and similar lines of lyrics/dynamics. Simply 'line' ? Remember the user cannot see why they are called loose -- maybe indirectly in the way these lines are placed in a second step after the staff lines, but the docs about that second step do not use the word 'loose'. The visible difference from regular staffs is that lyrics/dynamics have an affinity. They are attached, in their spacing behavior, to one a parent staff, or centered between two parent staffs, and negotiate with their siblings for space. - Keith ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: renaming vertical spacing inside systems props
On 10/31/10 3:00 PM, Keith E OHara k-ohara5...@oco.net wrote: On Fri, 29 Oct 2010 21:04:06 -0700, lilypond-devel-requ...@gnu.org wrote: Mark Polesky wrote Friday, October 29, 2010 11:27 PM I've thought about it, and I think I slightly favor the term loose line over non-staff line [...] Also loose-staff-spacing sounds too much like something that gives staves a loose spacing (rather than a tight spacing) to anyone coming to this for the first time. Thanks for doing this, Mark. It seems you want a one-word _noun_, to refer to either a line of lyrics and a line of dynamics, in the limited context of its placement relative to the neighboring staffs, and similar lines of lyrics/dynamics. Simply 'line' ? I think 'line' could easily be confused with a staff line. I think perhaps 'nonstaff' would be better. So we could have nonstaff-staff-spacing Remember the user cannot see why they are called loose -- maybe indirectly in the way these lines are placed in a second step after the staff lines, but the docs about that second step do not use the word 'loose'. But they might, once the terminology is finalized. The visible difference from regular staffs is that lyrics/dynamics have an affinity. They are attached, in their spacing behavior, to one a parent staff, or centered between two parent staffs, and negotiate with their siblings for space. This is a nice statement! Thanks! Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: renaming vertical spacing inside systems props
Mark Polesky markpole...@yahoo.com writes:
Guys,
Here are my proposals for renaming the properties related to
Vertical spacing inside systems.
* * * * * * * * * * * * * * *
I've thought about it, and I think I slightly favor the term
loose line over non-staff line; the word loose is
distinctive and much less likely to get tangled up with the
word staff (in the user's head, that is).
Disagree. A loose line in typesetting is one with loose (as opposed
to tight) spacing.
Instead of loose, I'd prefer free, wild, uhm non-staff,
unattached and likely a number of other expressions. But loose is
really misleading.
CURRENT NAME PROPOSED NAME ALTERNATE PROPOSAL
- --
next-staff staff-staff
default-next-staff default-staff-staff
inter-staffloose-staff [nonstaff-staff]
inter-loose-line loose-loose [nonstaff-nonstaff]
non-affinity loose-nonaffinity [nonstaff-nonaffinity]
between-staff inside-staffgroup
after-last-staff staffgroup-staff
Systematic or not, the new naming scheme gets less descriptive and more
ugly with every iteration.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: renaming vertical spacing inside systems props
On Sat, Oct 30, 2010 at 10:55 AM, David Kastrup d...@gnu.org wrote: Disagree. A loose line in typesetting is one with loose (as opposed to tight) spacing. Instead of loose, I'd prefer free, wild, uhm non-staff, unattached and likely a number of other expressions. But loose is really misleading. free is quite good. However, this only refers to vertical spacing (since Lyric lines are not free at all horizontally). Systematic or not, the new naming scheme gets less descriptive and more ugly with every iteration. OTOH, maybe we're just too used to the old naming scheme to appreciate the new one (well, I know I am :) Cheers, Valentin. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
renaming vertical spacing inside systems props
Guys, Here are my proposals for renaming the properties related to Vertical spacing inside systems. * * * * * * * * * * * * * * * I've thought about it, and I think I slightly favor the term loose line over non-staff line; the word loose is distinctive and much less likely to get tangled up with the word staff (in the user's head, that is). On the other hand, nonstaff-staff-spacing may be more intuitive than loose-staff-spacing. But if we call the property nonstaff-staff-spacing, I'd want to replace all references to loose lines with non-staff lines (or maybe nonstaff lines, without the hyphen?). Lastly, one property resists the item1-item2-spacing name format: currently named 'between-staff-spacing, it controls the spacing between staves within a staffgroup. I don't like the current name because it sounds like it controls the spacing between ungrouped staves too, but it doesn't. I'm proposing 'inside-staffgroup-spacing, which is clearer (I think) but not consistent with the item1-item2-spacing format. Please share your thoughts about these proposals. I want the prop names to be consistent and intuitive, and I'd like to come as close as possible to a general consensus. Hopefully this thread won't be as thorny as the last time: http://lists.gnu.org/archive/html/lilypond-devel/2010-10/msg00070.html If it helps, the current prop-names are explained in some detail in this (unfinished) patch: http://codereview.appspot.com/2642043/ Thanks! - Mark * * * * * * * * * * * * * * * Except for the 'inside-staffgroup property, the names of these properties follow the format item1-item2-spacing. Note that item2 is not necessarily below item1; for example, 'loose-staff-spacing will measure upwards from the loose line if 'staff-affinity = #UP. (I've omitted the -spacing suffix to save space.) CURRENT NAME PROPOSED NAME ALTERNATE PROPOSAL - -- next-staff staff-staff default-next-staff default-staff-staff inter-staffloose-staff [nonstaff-staff] inter-loose-line loose-loose [nonstaff-nonstaff] non-affinity loose-nonaffinity [nonstaff-nonaffinity] between-staff inside-staffgroup after-last-staff staffgroup-staff ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: renaming vertical spacing inside systems props
Mark Polesky wrote Friday, October 29, 2010 11:27 PM Here are my proposals for renaming the properties related to Vertical spacing inside systems. * * * * * * * * * * * * * * * I've thought about it, and I think I slightly favor the term loose line over non-staff line; the word loose is distinctive and much less likely to get tangled up with the word staff (in the user's head, that is). On the other hand, nonstaff-staff-spacing may be more intuitive than loose-staff-spacing. But if we call the property nonstaff-staff-spacing, I'd want to replace all references to loose lines with non-staff lines (or maybe nonstaff lines, without the hyphen?). I dislike loose lines. It doesn't immediately make me think, Ah, yes, that means my lyrics. Also loose-staff-spacing sounds too much like something that gives staves a loose spacing (rather than a tight spacing) to anyone coming to this for the first time. Nonstaff lines is definitely better, I think, and, yes, without the hyphen for consistency with the names of the spacing properties. Lastly, one property resists the item1-item2-spacing name format: currently named 'between-staff-spacing, it controls the spacing between staves within a staffgroup. I don't like the current name because it sounds like it controls the spacing between ungrouped staves too, but it doesn't. I'm proposing 'inside-staffgroup-spacing, which is clearer (I think) but not consistent with the item1-item2-spacing format. groupstaff-groupstaff-spacing ? groupedstaff-groupedstaff-spacing ? But I'm not unhappy with inside-staffgroup-spacing. BTW, what happens to nonstaff lines within staff groups? Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: renaming vertical spacing inside systems props
On 10/29/10 4:27 PM, Mark Polesky markpole...@yahoo.com wrote:
Guys,
Here are my proposals for renaming the properties related to
Vertical spacing inside systems.
* * * * * * * * * * * * * * *
I've thought about it, and I think I slightly favor the term
loose line over non-staff line; the word loose is
distinctive and much less likely to get tangled up with the
word staff (in the user's head, that is).
I think I do too. I couldn't come up with any better variable than
loose-line-spacing, so that's when I decided that calling them loose lines
might be the best.
On the other hand, nonstaff-staff-spacing may be more
intuitive than loose-staff-spacing. But if we call the
property nonstaff-staff-spacing, I'd want to replace all
references to loose lines with non-staff lines (or maybe
nonstaff lines, without the hyphen?).
I don't think it should be unhyphenated in the text; in the variable name
it's fine.
Lastly, one property resists the item1-item2-spacing name
format: currently named 'between-staff-spacing, it controls
the spacing between staves within a staffgroup. I don't
like the current name because it sounds like it controls the
spacing between ungrouped staves too, but it doesn't. I'm
proposing 'inside-staffgroup-spacing, which is clearer (I
think) but not consistent with the item1-item2-spacing
format.
I'd be OK with inside-staffgroup-spacing, but I think I prefer
grouped-staff-spacing or grouped-staves-spacing.
Please share your thoughts about these proposals. I want
the prop names to be consistent and intuitive, and I'd like
to come as close as possible to a general consensus.
Hopefully this thread won't be as thorny as the last time:
http://lists.gnu.org/archive/html/lilypond-devel/2010-10/msg00070.html
If it helps, the current prop-names are explained in some
detail in this (unfinished) patch:
http://codereview.appspot.com/2642043/
Thanks!
- Mark
* * * * * * * * * * * * * * *
Except for the 'inside-staffgroup property, the names of
these properties follow the format item1-item2-spacing.
Note that item2 is not necessarily below item1; for example,
'loose-staff-spacing will measure upwards from the loose
line if 'staff-affinity = #UP.
(I've omitted the -spacing suffix to save space.)
CURRENT NAME PROPOSED NAME ALTERNATE PROPOSAL
- --
next-staff staff-staff
default-next-staff default-staff-staff
Note: The names below also don't match the standard, because the standard is
that item1-item2 applies with item1 on the top, and item2 on the bottom.
However, for loose items, the affinity controls where the spacing applies.
So I think calling it loose-* makes sense.
inter-staffloose-staff [nonstaff-staff]
inter-loose-line loose-loose [nonstaff-nonstaff]
non-affinity loose-nonaffinity [nonstaff-nonaffinity]
between-staff inside-staffgroup
grouped-staff
after-last-staff staffgroup-staff
Thanks,
Carl
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
