Remove head- and foot-separation.

Remove head- and foot-separation.

[Mark Polesky, 2010-11-18 09:12:23]

If I understand correctly, head-separation and
foot-separation are gone.  This patch just removes the
vestiges from scm/ and ly/, but I suppose we should provide
a convert-ly rule?

So, in an earlier patch by Alexander...
http://codereview.appspot.com/1710046/diff/19001/Documentation/notation/spaci...
...he suggests that (using the updated names),
  head-separation = #x
should become
  top-system-spacing #'padding = #x

and that
  foot-separation = #x
should become
  last-bottom-spacing #'padding = #x

Is that precisely how the conversion should be made?  Can
someone verify this?  Should I push this patch or wait for
a convert-ly rule?

Thanks.
- Mark

[Graham Percival (old account), 2010-11-18 17:51:55]

On 2010/11/18 09:12:23, Mark Polesky wrote:
> Is that precisely how the conversion should be made?  Can
> someone verify this?  Should I push this patch or wait for
> a convert-ly rule?

I'm getting a bit confused with all the renamings, reorganizations, etc., and I
can't be the only one.  Could we slow things down slightly?  I'd like to see
only one spacing patch "on the table" at once, and leaving 24 hours after the
final draft of each patch for comments from people in all time zones.

For this specific patch,
1) have people agreed to this specific naming change?
2) if the convert-ly change isn't part of this commit, it should be in the next
commit.  I think you should wait until you have both patches ready and approved,
before pushing either of them.

[Mark Polesky, 2010-11-19 07:02:35]

On 2010/11/18 17:51:55, Graham Percival wrote:
> I'm getting a bit confused with all the renamings,
> reorganizations, etc., and I can't be the only one.  Could
> we slow things down slightly?  I'd like to see only one
> spacing patch "on the table" at once, and leaving 24 hours
> after the final draft of each patch for comments from
> people in all time zones.
>
> For this specific patch,
> 1) have people agreed to this specific naming change?
> 2) if the convert-ly change isn't part of this commit, it
> should be in the next commit.  I think you should wait
> until you have both patches ready and approved, before
> pushing either of them.

Graham,

this patch is not about changing the names of head- and
foot-separation.  Those variables are already gone; they're
bleedin' demised.  When they ceased to be, the functionality
they provided was presumably achievable using the new
spacing alists, but a convert-ly rule to automate this was
never written.

This patch is about cleaning up the outdated code, and could
also be about adding a convert-ly rule that should have been
put there a while ago.  There's nothing to vote on or debate
about; I just don't know the proper conversion.  Once
someone verifies the right way to duplicate the old
functionality, I can add the convert-ly rule to this patch
and be done with it.

- Mark

[Patrick McCarty, 2010-11-19 07:55:46]

On 2010/11/19 07:02:35, Mark Polesky wrote:
> When they ceased to be, the functionality
> they provided was presumably achievable using the new
> spacing alists, but a convert-ly rule to automate this was
> never written.

IIUC, this would not be a straightforward conversion that regular expressions
can (easily) deal with.  I would suggest a NOT SMART rule that recommends the
use of the new spacing alists.

-Patrick

[perpeduumimmobile, 2010-11-19 10:06:33]

On 2010/11/19 07:55:46, Patrick McCarty wrote:
> IIUC, this would not be a straightforward conversion that regular
> expressions can (easily) deal with.  I would suggest a NOT SMART
> rule that recommends the use of the new spacing alists.

I second this.  It would be possible to convert the *-separation value to an
offset to the corresponding 'padding values, but the result most probably will
not be entirely identical (due to the other values in the 'spacing alist), and
we'd have to deal with specifications in the 4\mm style.  I don't think these
apply to 'padding in a straightforward way?

Cheers,
Alexander

[Mark Polesky, 2010-11-19 17:26:49]

On 2010/11/19 07:55:46, Patrick McCarty wrote:
> I would suggest a NOT SMART rule that recommends the
> use of the new spacing alists.

At which release point should this rule be entered?  This
commit was pushed 2.13.4:
2f38710 Rewrite the vertical layout of staves/systems.

- Mark

[Patrick McCarty, 2010-11-19 19:53:33]

On 2010/11/19 17:26:49, Mark Polesky wrote:
> On 2010/11/19 07:55:46, Patrick McCarty wrote:
> > I would suggest a NOT SMART rule that recommends the
> > use of the new spacing alists.
> 
> At which release point should this rule be entered?  This
> commit was pushed 2.13.4:
> 2f38710 Rewrite the vertical layout of staves/systems.

I think it should be for 2.13.40.

This is my reasoning: even though head- and foot-separation became obsolete in
2.13.4, adding a convert-ly rule for 2.13.4 would mean that files with `\version
"2.13.4"' or greater will not see the NOT_SMART rule.  That's why I think
2.13.40 would be more appropriate and practical, from a user's standpoint.

-Patrick

[Patrick McCarty, 2010-11-19 20:04:28]

On 2010/11/19 10:06:33, perpeduumimmobile wrote:
> On 2010/11/19 07:55:46, Patrick McCarty wrote:
> > IIUC, this would not be a straightforward conversion that regular
> > expressions can (easily) deal with.  I would suggest a NOT SMART
> > rule that recommends the use of the new spacing alists.
> 
> I second this.  It would be possible to convert the *-separation value to an
> offset to the corresponding 'padding values, but the result most probably will
> not be entirely identical (due to the other values in the 'spacing alist), and
> we'd have to deal with specifications in the 4\mm style.  I don't think these
> apply to 'padding in a straightforward way?

Yes, I don't think so either.

Also, the fact that most (if not all) of the new spacing properties use relative
values (staff spaces) means that we would need to convert the absolute values,
such as 4\mm, into their staff space equivalents.  I don't think it would be
worth writing a real conversion rule for this.

-Patrick

[Mark Polesky, 2010-11-19 23:23:20]

Okay, this small patch is finished.  Graham, would you like
me to wait to push this for any reason?

- Mark

[Graham Percival (old account), 2010-11-20 00:12:19]

On 2010/11/19 23:23:20, Mark Polesky wrote:
> Okay, this small patch is finished.  Graham, would you like
> me to wait to push this for any reason?

The patch looks ok to me.  I agree with the 2.13.40 convert-ly rule, and the
NOT_SMART-ness.  At the moment, I can't think of any reason why somebody would
jump in and disagree with the patch.  However, that doesn't mean that there
*aren't* any good reasons to disagree with the patch.

I would rather wait another 23.5 hours, to give people in all timezones
(regardless of geographic location; I'm living in Pacific Standard Time at the
moment) a chance to object.  I promise that I will not release .40 during that
timeframe, so don't worry about missing that "deadline".

[Keith, 2010-11-20 01:23:07]

http://codereview.appspot.com/3199041/diff/10001/python/convertrules.py
File python/convertrules.py (right):

http://codereview.appspot.com/3199041/diff/10001/python/convertrules.py#newco...
python/convertrules.py:3101: stderr_write("Adjust settings for
top-system-spacing instead.\n")
Misplaced underscore tag for translation?  I would think the sentence above gets
marked (_(..)) for translation, while the variable name next line up does not
really need to be marked.   Ditto, five lines down.

[Mark Polesky, 2010-11-20 08:10:55]

On 2010/11/20 01:23:07, Keith wrote:
> Misplaced underscore tag for translation?

Oops.  Fixed, thanks.

On 2010/11/20 00:12:19, Graham Percival wrote:
> I would rather wait another 23.5 hours, to give people in
> all timezones (regardless of geographic location; I'm
> living in Pacific Standard Time at the moment) a chance to
> object.

Alright, Graham, I'll push this some time after
23:49 GMT 2010-11-20 if no one objects by then!

- Mark

[Trevor Daniels, 2010-11-20 08:44:51]

LGTM

[Mark Polesky, 2010-11-21 13:55:54]

On 2010/11/20 08:44:51, Trevor Daniels wrote:
> LGTM

Patch pushed and issue closed.