lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: names of vertical spacing dimensions


From: Carl Sorensen
Subject: Re: names of vertical spacing dimensions
Date: Wed, 13 Oct 2010 17:50:08 -0600



On 10/13/10 2:40 PM, "David Kastrup" <address@hidden> wrote:

> Carl Sorensen <address@hidden> writes:
> 
>> On 10/13/10 8:29 AM, "David Kastrup" <address@hidden> wrote:
>> 
>>> Carl Sorensen <address@hidden> writes:
>>> 
>>>> David Kastrup <address@hidden> writes:
>>>>> 
>>>> 
>>>>> 
>>>>> So my fear is that the new scheme is both strictly logical, and not
>>>>> useful for specifying a coherent document layout.
>>>> 
>>>> But the new scheme is just a restatement (renaming) of the current
>>>> scheme.
>>> 
>>> The renaming moves from a document design perspective (high level) to an
>>> implementation one (low level).  The use of those variables, however, is
>>> inside of the layout block which is supposed to be a document design
>>> specification.
>>> 
>>> It also moves from an essentially one-dimensional parameter realm
>>> "above-x, between-x, below-x, above-y, between-y, below-y" to a
>>> two-dimensional matrix "between-x-x, between-x-y" ...
>>> 
>>> This does not make it feasible to introduce further layout components
>>> for spacing since the parameter growth becomes quadratic.
>> 
>> So you think it's better to have vague names for a fundamentally
>> quadratic spacing scheme, instead of having names that reflect the
>> quadratic nature of the scheme?
>> 
>> I don't think I agree with this position.
> 
> Can we put the strawmen aside?
> 
> The point is that we want a sane way of specifying document layout
> parameters.  The current naming scheme resembles that desire.  The
> current code not.  Adapting the naming scheme to the deficiencies of the
> code is going the wrong way in my opinion.

As far as I can see, we have no plans to change the code.  At least nobody
is stepping forward to do so.  It seems to me that the unspecified new code
is a strawman.

Accepting the limitation that we need to stay with the current code (which I
believe to be a real limitation), it seems to me that we have three
alternatives:

1) Leave the variable names and the docs as they currently are.  This is a
confusing situation; as near as I can tell Mark and Joe are the only two
people in the world who completely understand the meaning of the current
variables.  I think this situation is untenable.

2) Leave the variable names as they currently are, but rewrite the docs to
map the current "sort-of-sane" naming scheme to the quadratic code scheme.
That is, we make a table for each spacing parameter, and explain the upper
and lower bound of the spacing item.  This keeps the naming scheme that
resembles the desired behavior.  It has the deficiency that the naming
scheme does not match current behavior, and that we need to look at the docs
to see what the current spacing terms really mean.

3) Change the variable names to reflect the current code.  This has the
disadvantage of codifying the current quadratic code in the naming scheme,
but the advantage of having the names reflect the current behavior.

Do you feel that these alternatives are strawmen?  I'm not trying to make
strawmen -- I'm trying to clarify what I think the current decision is.

Are there other alternatives that you think are feasible?

Once we have identified a set of alternatives to choose among, we can argue
for what the best alternative is.

Thanks,

Carl




reply via email to

[Prev in Thread] Current Thread [Next in Thread]