vert. spacing: Rename properties (lily, scm).

vert. spacing: Rename properties (lily, scm).

[Mark Polesky, 2010-11-11 03:53:44]

Here's a new patch-set for renaming the vertical spacing
grob properties.  But...

I'm kind of going in circles trying to decide where to put
some things:

1) individual alist-key descriptions
2) individual grob-property descriptions
3) non-staff line reference-points

I wanted to move the property descriptions to the IR.  Easy
enough, and this removes clutter from the NR.  Now, the
alist-keys -- currently they're explained via a
cross-reference to the section on the \paper variables.
However, I began to think that a better place for the
alist-key descriptions is at the top of the
axis-group-interface page in the IR (much like the 'details
keys are explained at the top of the beam-interface page).

But it felt weird to refer to "reference points" in the IR
without also explaining them too, so I included the table
explaining that, and now the axis-group-interface page is
looking cluttered.

Furthermore, if I'm going to put alist-key descriptions on
the axis-group-interface page, I really should put them also
on the staff-grouper-interface page, so now things seem even
more cluttered than before.

One thing that may help is a dedicated
vertical-axis-group-interface page, which we don't currently
have.  Shouldn't we add one?

Anyway, this patch set ends up having some duplication:

reference-points are discussed in
  NR 4.4.1 Within-system spacing properties
  IR 3.2.7 axis-group-interface

spacing alist-keys are discussed in
  NR 4.1.2 Flexible vertical dimensions
  IR 3.2.7 axis-group-interface
  IR 3.2.97 staff-grouper-interface

If anyone has a better idea, let me know.

Sorry it's so huge.  There were a gazillion trailing spaces
that got stripped in some of the translated docs, but I
tried to organize this so it's easier to parse.  Also, some
regression tests were renamed, so you may have to 'git add'?
I don't know.

Thanks!
- Mark

[Carl, 2010-11-11 04:36:32]

On 2010/11/11 03:53:44, Mark Polesky wrote:
> Here's a new patch-set for renaming the vertical spacing
> grob properties.  But...
> 
> I'm kind of going in circles trying to decide where to put
> some things:
> 
> 1) individual alist-key descriptions
> 2) individual grob-property descriptions
> 3) non-staff line reference-points
> 
> I wanted to move the property descriptions to the IR.  Easy
> enough, and this removes clutter from the NR.  

I'm not sure exactly what you're talking about here -- we don't have a patch
covering this part.

I'm a little concerned with the verbosity of the property descriptions in the
IR.  Such verbose descriptions represent a change in style that I think might
need to be discussed.

> Now, the
> alist-keys -- currently they're explained via a
> cross-reference to the section on the \paper variables.
> However, I began to think that a better place for the
> alist-key descriptions is at the top of the
> axis-group-interface page in the IR

In my opinion, this is too much detail in the IR.

> (much like the 'details
> keys are explained at the top of the beam-interface page).

The details keys are not really explained -- it's more that they're listed.
> 
> But it felt weird to refer to "reference points" in the IR
> without also explaining them too, so I included the table
> explaining that, and now the axis-group-interface page is
> looking cluttered.

Yes -- IMO it's definitely too much.  Go ahead and leave the "reference points"
in the IR without explanation.

> 
> Furthermore, if I'm going to put alist-key descriptions on
> the axis-group-interface page, I really should put them also
> on the staff-grouper-interface page, so now things seem even
> more cluttered than before.

I agree.  In order to avoid clutter, these need to be more terse, I think.

> 
> One thing that may help is a dedicated
> vertical-axis-group-interface page, which we don't currently
> have.  Shouldn't we add one?
> 
> Anyway, this patch set ends up having some duplication:
> 
> reference-points are discussed in
>   NR 4.4.1 Within-system spacing properties

Keep this one.

>   IR 3.2.7 axis-group-interface

Lose this one, IMO.

> 
> spacing alist-keys are discussed in
>   NR 4.1.2 Flexible vertical dimensions

Keep this one.

>   IR 3.2.7 axis-group-interface
>   IR 3.2.97 staff-grouper-interface

Lose (or severely trim) these, IMO.

> 
> If anyone has a better idea, let me know.

I actually really like the way it's currently done in the IR. 
next-staff-spacing has the description of the alist properties; all the rest of
the spacing properties just refer to next-staff-spacing.

I think that staff-staff-spacing should probably have the description, and
everything else should refer to staff-staff-spacing.

I appreciate your working hard on this project.  It's a HUGE project, and I
think it will make a big difference to the LilyPond documentation.

But I do have a concern that it's too verbose, in general.  Way back in the dark
ages when we started on the GDP, Graham said something that I didn't really
agree with, but now I do.  Basically it was "You'll know we've got good
documentation when we can't think of anything else to remove".  He was speaking
of the Notation Reference, not the Learning Manual, which should be a bit less
terse.

I think in this proposed patch there is some stuff that can be removed.  It
seems too much in Learning Manual style, and not enough in Notation Reference
style.

That being said, you're much more of an expert on this than me.  And I think
this patch is better than what's currently there.  It would be an improvement to
have it, so I wouldn't stand in its way.

Thanks for the great work!

Carl

[Carl, 2010-11-11 04:37:17]

Many of my general comments were in my reply to your message.  There are some
specifics in the files here.

Thanks,

Carl

http://codereview.appspot.com/3031041/diff/30001/lily/axis-group-interface.cc
File lily/axis-group-interface.cc (right):

http://codereview.appspot.com/3031041/diff/30001/lily/axis-group-interface.cc...
lily/axis-group-interface.cc:780: "The following properties of the
@code{VerticalAxisGroup}"
I'm uncomfortable with having all this documentation in the docstring.  But
maybe I shouldn't be.

It seems to me that each of the properties defined here is defined as a grob
property in scm/define-grob-properties.scm.  

I guess the weakness here is that we don't have a good system for defining
nested properties.  In particular, each of these properties is a property of
type "spacing" (I'm not quibbling about the terminology right now), and we don't
have anywhere to say what subproperties a property of type spacing has.

The interface page in the IR *might* be the right place to put it, but I think
it is better to have the full description in the NR, and a short description in
the IR.

http://codereview.appspot.com/3031041/diff/30001/scm/define-grob-properties.scm
File scm/define-grob-properties.scm (right):

http://codereview.appspot.com/3031041/diff/30001/scm/define-grob-properties.s...
scm/define-grob-properties.scm:777: consecutive staves within the same
@emph{region}, even if one or
I'm uncomfortable about having this much information about the performance in
the docstring for a property.  It seems inconsistent with the rest of the
property docstrings.

But I'm not sure I know a better way to do it....

http://codereview.appspot.com/3031041/diff/30001/scm/define-grob-properties.s...
scm/define-grob-properties.scm:779: two staves.  For the @code{StaffGrouper}
version of this property,
I don't think there are two different "versions" of the property.  The
difference is what type of Grob the property is applied to.

[Trevor Daniels, 2010-11-11 08:53:29]

In general I agree with Carl's comments.  I've suggested in a couple of places
where I'd like to see the IR material truncated.  The full description of the
properties should go in the NR, perhaps in an appendix if you think it's too
technical.

http://codereview.appspot.com/3031041/diff/30001/Documentation/notation/spaci...
File Documentation/notation/spacing.itely (right):

http://codereview.appspot.com/3031041/diff/30001/Documentation/notation/spaci...
Documentation/notation/spacing.itely:1496: @code{VerticalAxisGroup} are:
VerticalAxisGroup is a unique object (in this context), so should not be
preceded by "the", although this might be debatable.  I'd prefer to see "the
VerticalAxisGroup layout object", which is incontravertably correct.  Same for
the names of other grobs.

http://codereview.appspot.com/3031041/diff/30001/lily/axis-group-interface.cc
File lily/axis-group-interface.cc (right):

http://codereview.appspot.com/3031041/diff/30001/lily/axis-group-interface.cc...
lily/axis-group-interface.cc:780: "The following properties of the
@code{VerticalAxisGroup}"
On 2010/11/11 04:37:18, Carl wrote:

> The interface page in the IR *might* be the right place
> to put it, but I think it is better to have the full
> description in the NR, and a short description in
> the IR.

I agree.  If the material in the NR appears too technical, or spoils the flow,
it would be in keeping with the general style of the NR to place it in an
appendix of the NR, not in the IR.

http://codereview.appspot.com/3031041/diff/30001/lily/axis-group-interface.cc...
lily/axis-group-interface.cc:798: " whitespace between two items, measured in
staff-spaces."
Stop here.  Repeat with rest in NR.

http://codereview.appspot.com/3031041/diff/30001/lily/axis-group-interface.cc...
lily/axis-group-interface.cc:805: " between the @emph{reference points} of the
two items"
Stop here.  Repeat with rest in NR.  (Ditto for other properties)

[Mark Polesky, 2010-11-12 00:26:23]

Carl and Trevor -

Thanks for looking this over.  Here's a new patch set.  I
decided to revert the revisions to the NR for the moment.
That's easy enough to revise later on.  For now, I'd like to
push this version, and make any smaller changes later.  The
basic differences from the previous patch set are in:

lily/axis-group-interface.cc
lily/staff-grouper-interface.cc
scm/define-grob-properties.scm

Of course you just click on the "Delta from patch set 12"
links.  I removed a lot of excess wording, I suppose.  Let
me know if this is okay to push.  If approved, this will be
pushed in 10 commits (all at once), corresponding to Patch
sets 1-10 as listed at Rietveld.

Thanks yet again!
- Mark

[Carl, 2010-11-12 02:46:18]

Thanks again for your work on this, Mark.

I think the spacing-alist description belongs in one of the grob properties;
it's the value of a property, not a property of an interface.

I much prefer this to the previous patch.

I had an idea about the name of the StaffGrouper staff-staff-spacing property,
when I was reading (and being confused about) how it worked.  See my comment
below.

If you disagree with any of these suggestions, I'm happy to have a discussion. 
I don't want to force my opinion on any of these.

Thanks,

Carl

http://codereview.appspot.com/3031041/diff/40001/lily/axis-group-interface.cc
File lily/axis-group-interface.cc (right):

http://codereview.appspot.com/3031041/diff/40001/lily/axis-group-interface.cc...
lily/axis-group-interface.cc:780: "The following keys may be set in the spacing
alists:\n"
I'd prefer to have the keys described under the staff-staff-spacing grob
property, I think.

http://codereview.appspot.com/3031041/diff/40001/lily/staff-grouper-interface.cc
File lily/staff-grouper-interface.cc (right):

http://codereview.appspot.com/3031041/diff/40001/lily/staff-grouper-interface...
lily/staff-grouper-interface.cc:42: "The following keys may be set in the
spacing alists:\n"
As with the axis-group interface, I think the spacing-alist description belongs
in the description of the staff-staff-spacing property (or perhaps the
default-staff-staff-spacing property), rather than in the interface.

http://codereview.appspot.com/3031041/diff/40001/scm/define-grob-properties.scm
File scm/define-grob-properties.scm (right):

http://codereview.appspot.com/3031041/diff/40001/scm/define-grob-properties.s...
scm/define-grob-properties.scm:587: (nonstaff-nonstaff-spacing ,list? "The
flexible distance
Instead of "The flexible distance", I think I'd say "The spacing alist
controlling the distance", with a reference that says "see staff-staff-spacing
for a description of a spacing alist."

http://codereview.appspot.com/3031041/diff/40001/scm/define-grob-properties.s...
scm/define-grob-properties.scm:592: (nonstaff-relatedstaff-spacing ,list? "The
flexible distance
Again, s/flexible/spacing alist controlling/

http://codereview.appspot.com/3031041/diff/40001/scm/define-grob-properties.s...
scm/define-grob-properties.scm:772: two staves.  When applied to a
@code{StaffGrouper} grob,
Trevor suggested "layout object" instead of "grob".  While it's longer, I think
it may be clearer here.

http://codereview.appspot.com/3031041/diff/40001/scm/define-grob-properties.s...
scm/define-grob-properties.scm:774: @code{VerticalAxisGroup} grob, @q{region}
refers to an entire
This is confusing to me, because it seemed on first reading to imply that a
setting of staff-staff-spacing for a VerticalAxisGroup would apply to all staves
in a system, rather than just to the current staff.

The challenge is that this is true within a StaffGrouper.  To a certain extent,
setting staff-staff-spacing for the StaffGrouper is equivalent to setting
default-staff-staff-spacing for all the staves in the group except for the last
one.

Hmm -- maybe instead of calling it staff-staff-spacing, we should call it
default-staff-staff-spacing.  Then we'd have a system wide
default-staff-staff-spacing, a staffgroup default-staff-staff-spacing, and
individual staff staff-staff-spacing.  Specified individual staff
staff-staff-spacing always overrides the defaults, and the staffgroup default
overrides the system wide default.

Also, here is where I think I would like to see the description of a
spacing-alist.

http://codereview.appspot.com/3031041/diff/40001/scm/define-grob-properties.s...
scm/define-grob-properties.scm:788: @code{VerticalAxisGroup} grob will be used
instead for any staff
Is this true for *any* staff, or just for the *last* staff?  In my mind,
staffgroup-staff-spacing is the spacing between the last staff of the group and
the next staff below.

http://codereview.appspot.com/3031041/diff/40001/scm/define-grob-properties.s...
scm/define-grob-properties.scm:790: @code{staffgroup-staff-spacing} and
@code{staff-staff-spacing} (of
I think this explanation should just be part of the default-staff-staff-spacing
property, rather than being listed in multiple places.

[Trevor Daniels, 2010-11-12 09:06:06]

Apart from the placement of the descriptive text in the IR, which I think is
debatable, I agree with Carl's comments.

Thanks again Mark.  Every iteration is an improvement.  I think we're nearly
there!

Trevor

http://codereview.appspot.com/3031041/diff/40001/lily/axis-group-interface.cc
File lily/axis-group-interface.cc (right):

http://codereview.appspot.com/3031041/diff/40001/lily/axis-group-interface.cc...
lily/axis-group-interface.cc:780: "The following keys may be set in the spacing
alists:\n"
I'm not sure.  The current description is in the interface.
Isn't the standard practice to place descriptions in the interface and only the
values set for particular grobs in the grob description?  (I was about to say we
should do the same as 'details, but the description of 'details is very poor;
not a good model.)

[Carl, 2010-11-12 11:04:21]

On 2010/11/12 09:06:06, Trevor Daniels wrote:

> 
>
http://codereview.appspot.com/3031041/diff/40001/lily/axis-group-interface.cc...
> lily/axis-group-interface.cc:780: "The following keys may be set in the
spacing
> alists:\n"
> I'm not sure.  The current description is in the interface.

If you look at the delta from set 12, you think the current description is in
the interface.  If you look at the delta from master, you'll find there is no
description in the interface currently.

> Isn't the standard practice to place descriptions in the interface and only
the
> values set for particular grobs in the grob description?  (I was about to say
we
> should do the same as 'details, but the description of 'details is very poor;
> not a good model.)

As far as I can see, the only time we place descriptions in the interface is
when the property can have different values depending on the interface in which
it's used (as in 'details).  So the beam-interface has a list of the 'details
that can be set for beams.

In this case, the spacing-alist has the same entries for all the interfaces, so
there's no need to repeat the information in the different interfaces.  The best
place to put the definition, IMO, is in the description of the spacing property
that is either most general or most commonly set.  See the current behavior in
the IR, section 3.3, of between-staff-spacing and next-staff-spacing.

break-aligned-interface currently has the definition of space specifications in
the interface description.  I think it would be nicer to have the space
specifications as part of the description of the space-alist property, where it
would describe the distance element of the tuples in the space-alist.

The reasoning behind this is that when it's done this way, every time we see the
space-alist, we have the explanation, without having to duplicate the
information in each interface that uses space-alist.  Furthermore, if I'm
looking at the space-alist property, I know how to set its entries without
having to find the interface.

Thanks,

Carl

[Trevor Daniels, 2010-11-12 16:36:00]

You're right, Carl.  I'd misunderstood how this works.

Trevor

[Mark Polesky, 2010-11-12 17:19:17]

On 2010/11/12 02:46:18, Carl wrote:
> Thanks again for your work on this, Mark.

Carl, I think that everything you wrote in this post is
agreeable, including changing the StaffGrouper property name
to "default-staff-staff-spacing".  I'm happy to implement
all of these changes, but this will have to wait till later
today.

One tiny modification I propose is to put the alist-key
descriptions into "default-staff-staff-" instead of
"staff-staff-" because otherwise the prop descriptions on
the IR staff-grouper-interface page would be referring to a
prop description that's not there.  That's actually the
situation currently: the references to "next-staff-spacing"
in IR 3.2.97 are nowhere to be found.

Describing the alist-keys in the prop-description that's
common to both grobs allows the alist to appear in the IR
pages of both grobs without the need for duplication in
define-grob-properties.scm.  Sound good to you?

Trevor, any objection to Carl's renaming?  It's logical and
consistent in my mind, so I'd like to do it.

- Mark

[Mark Polesky, 2010-11-12 21:53:41]

On 2010/11/12 17:19:17, Mark Polesky wrote:
> Trevor, any objection to Carl's renaming?  It's logical and
> consistent in my mind, so I'd like to do it.

Sorry to keep changing my mind...  In truth I'm still questioning it.
I might like to keep staff-staff-spacing for the StaffGrouper prop.
I'm thinking it over, and I'll get back to you.

- Mark

[Mark Polesky, 2010-11-12 22:48:57]

On 2010/11/12 21:53:41, Mark Polesky wrote:
> I might like to keep staff-staff-spacing for the StaffGrouper
> prop. I'm thinking it over, and I'll get back to you.

Guys, I'd rather not change StaffGrouper's
'staff-staff-spacing to 'default-staff-staff-spacing.  The
big reason for me is that it is no more a "default spacing"
than its companion property 'staffgroup-staff-spacing, and
it would be very weird to call that one
'default-staffgroup-staff-spacing.

One way of seeing the interaction between the involved
properties is as a cascade of fallback options, with
VerticalAxisGroup's 'staff-staff-spacing being the first one
to consult, and VerticalAxisGroup's
'default-staff-staff-spacing being the last resort when
nothing else is available:

1)  Staff.VerticalAxisGroup #'staff-staff-spacing
    - distance between this staff and the one below it in
      the same system.

2a) StaffGroup.StaffGrouper #'staff-staff-spacing
    - the settings to use for #1 when unset, for all staves
      in the staff-group except the last one.

2b) StaffGroup.StaffGrouper #'staffgroup-staff-spacing
    - the settings to use for #1 when unset, for the last
      staff in the staff-group.

3)  Staff.VerticalAxisGroup #'default-staff-staff-spacing
    - the settings to use for #1 when none of the above are
      available.

Viewed in this way, it's clear that the StaffGrouper
properties are on the same "cascade level", each applying to
one of two cases within the staff-group (last-staff or
not-last-staff).  So I think we should reserve the word
"default" for #3, which is the real end of the line, as I
see it.

If you're okay with that logic, then all that remains is to
find a better way to explain both #1 and #2a using a single
property-description, since they share the same name.  I
propose this:

staff-staff-spacing

When applied to a staff-group's StaffGrouper grob, this
spacing alist controls the distance between consecutive
staves within the staff-group.  When applied to a staff's
VerticalAxisGroup grob, it controls the distance between the
staff and the nearest staff below it, replacing any settings
inherited from the StaffGrouper grob of the containing
staff-group, if there is one.

What do you think?

Thanks.
- Mark

[Carl, 2010-11-12 22:53:43]

On 2010/11/12 22:48:57, Mark Polesky wrote:

> 
> staff-staff-spacing
> 
> When applied to a staff-group's StaffGrouper grob, this
> spacing alist controls the distance between consecutive
> staves within the staff-group.  When applied to a staff's
> VerticalAxisGroup grob, it controls the distance between the
> staff and the nearest staff below it, replacing any settings
> inherited from the StaffGrouper grob of the containing
> staff-group, if there is one.
> 
> What do you think?
> 

I like it.  I think it is terse, and it avoids confusion.

Thanks,

Carl

[Carl, 2010-11-12 22:57:09]

On 2010/11/12 17:19:17, Mark Polesky wrote:
> On 2010/11/12 02:46:18, Carl wrote:
> One tiny modification I propose is to put the alist-key
> descriptions into "default-staff-staff-" instead of
> "staff-staff-" because otherwise the prop descriptions on
> the IR staff-grouper-interface page would be referring to a
> prop description that's not there.  That's actually the
> situation currently: the references to "next-staff-spacing"
> in IR 3.2.97 are nowhere to be found.
> 
> Describing the alist-keys in the prop-description that's
> common to both grobs allows the alist to appear in the IR
> pages of both grobs without the need for duplication in
> define-grob-properties.scm.  Sound good to you?

Sounds great.  I haven't thought carefully enough about it to have strong
feelings about which property it should be explained in.  The important thing, I
think, is to explain it in one and only one.  And the choice you propose sounds
excellent.

Thanks,

Carl

[t.daniels_treda.co.uk, 2010-11-13 00:34:36]

markpolesky@gmail.com wrote Friday, November 12, 2010 10:48 PM


> On 2010/11/12 21:53:41, Mark Polesky wrote:
>> I might like to keep staff-staff-spacing for the StaffGrouper
>> prop. I'm thinking it over, and I'll get back to you.
> 
> Guys, I'd rather not change StaffGrouper's
> 'staff-staff-spacing to 'default-staff-staff-spacing.  The
> big reason for me is that it is no more a "default spacing"
> than its companion property 'staffgroup-staff-spacing, and
> it would be very weird to call that one
> 'default-staffgroup-staff-spacing.
[snip] 
> If you're okay with that logic, then all that remains is to
> find a better way to explain both #1 and #2a using a single
> property-description, since they share the same name.  I
> propose this:
> 
> staff-staff-spacing
> 
> When applied to a staff-group's StaffGrouper grob, this
> spacing alist controls the distance between consecutive
> staves within the staff-group.  When applied to a staff's
> VerticalAxisGroup grob, it controls the distance between the
> staff and the nearest staff below it, replacing any settings
> inherited from the StaffGrouper grob of the containing
> staff-group, if there is one.
> 
> What do you think?

All LGTM.  Time to get this launched, I think.

Trevor

[Mark Polesky, 2010-11-13 00:50:51]

Here's the latest patch set.

I think I made every suggestion except one.  I didn't
change "grob" to "layout object", just because "grob"
appears as a word so often in define-grob-properties.scm,
and "layout" doesn't appear once:

$ git grep -c -e "\<grob\>" --and --not -e "[-:]grob" \
  scm/define-grob-properties.scm | xargs echo
scm/define-grob-properties.scm:43

$ git grep -c "layout" scm/define-grob-properties.scm | xargs echo
[...nothing...]

So, could it possibly be?  Is this okay to push?
- Mark

[Carl, 2010-11-13 01:09:24]

On 2010/11/13 00:50:51, Mark Polesky wrote:
> So, could it possibly be?  Is this okay to push?

I like it a lot!

Just one more thing -- James has captured new default values from Keith Ohara's
work.  Perhaps these new default values should be added as part of this patch.

<http://codereview.appspot.com/3061041>

Or maybe it could be a separate patch to push immediately after.

But this change will invalidate James's patch, so we ought to at least be sure
to handle that properly.

Thanks,

Carl

[Carl, 2010-11-13 01:10:47]

LGTM.

What happened to the description of reference points for various objects?  Has
that disappeared, or did I just miss it?

Will it be coming back somewhere?

Thanks,

Carl

http://codereview.appspot.com/3031041/diff/64001/Documentation/learning/funda...
File Documentation/learning/fundamental.itely (right):

http://codereview.appspot.com/3031041/diff/64001/Documentation/learning/funda...
Documentation/learning/fundamental.itely:2845: Currently, it is not possible to
modify the @code{stretchability}
Documentation/notation/spacing.itely says that we can modify the stretchability
sub-property only, using 

\override VerticalAxisGroup #'staff-staff-spacing #'stretchability = 9

Does this require a change here?

This change could easily be a separate patch, since it's a separate issue.

[Mark Polesky, 2010-11-13 01:56:56]

Carl and Trevor,

The patch is pushed.  Thanks so much for your help!

On 2010/11/13 01:10:47, Carl wrote:
> But this change will invalidate James's patch, so we ought
> to at least be sure to handle that properly.

Yep.  I emailed him on -devel.

> What happened to the description of reference points for
> various objects?  Has that disappeared, or did I just miss
> it?

It's sitting comfortably where it has been for some time,
around line 1500 in Documentation/notation/spacing.itely, in
NR 4.4.1 "Within-system spacing properties".

>
http://codereview.appspot.com/3031041/diff/64001/Documentation/learning/funda...
> Documentation/learning/fundamental.itely:2845: Currently,
> it is not possible to modify the @code{stretchability}
> Documentation/notation/spacing.itely says that we can
> modify the stretchability sub-property only, using
>
> \override VerticalAxisGroup #'staff-staff-spacing
> #'stretchability = 9
>
> Does this require a change here?

Yes.  This was written in July with commit #6734448, and
Neil fixed the issue two weeks ago with commit #93c53eb.
Best to fix it now or make a note of it somewhere other than
this Rietveld thread.

- Mark

[c_sorensen, 2010-11-13 02:54:58]

On 11/12/10 6:56 PM, "markpolesky@gmail.com" <markpolesky@gmail.com> wrote:


> 
>> Does this require a change here?
> 
> Yes.  This was written in July with commit #6734448, and
> Neil fixed the issue two weeks ago with commit #93c53eb.
> Best to fix it now or make a note of it somewhere other than
> this Rietveld thread.

OK, fixed and pushed.

Carl

[t.daniels_treda.co.uk, 2010-11-13 10:06:36]

Mark, you wrote Saturday, November 13, 2010 12:50 AM


> I think I made every suggestion except one.  I didn't
> change "grob" to "layout object", just because "grob"
> appears as a word so often in define-grob-properties.scm,
> and "layout" doesn't appear once:

That may be so, but it's a standard term in the IR
and the documentation.  See IR 3.1 which is called
All layout objects.

Grob is the name of those layout objects that actually
deal with something pictorial rather than positional.

No big deal, though.

Trevor
 

[t.daniels_treda.co.uk, 2010-11-13 10:06:36]

Mark, you wrote Saturday, November 13, 2010 12:50 AM


> I think I made every suggestion except one.  I didn't
> change "grob" to "layout object", just because "grob"
> appears as a word so often in define-grob-properties.scm,
> and "layout" doesn't appear once:

That may be so, but it's a standard term in the IR
and the documentation.  See IR 3.1 which is called
All layout objects.

Grob is the name of those layout objects that actually
deal with something pictorial rather than positional.

No big deal, though.

Trevor