lilypond-devel
[Top][All Lists]
Advanced

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

Re: Gets rid of length in the docs. (issue 4965053)


From: Mike Solomon
Subject: Re: Gets rid of length in the docs. (issue 4965053)
Date: Mon, 29 Aug 2011 10:11:19 +0200

On Aug 29, 2011, at 9:53 AM, Graham Percival wrote:

> On Mon, Aug 29, 2011 at 07:45:04AM +0000, address@hidden wrote:
>> I can't say I like this change: it makes a complex user
>> interface more complex.  Shouldn't we be moving in the
>> opposite direction?
> 

I disagree.
There used to be length, stem-begin, stem-end, and Y-extent properties for stem 
- all of which were combinations of each other in some form.  In theory, 
stem-begin + length * dir = stem-end.  (cons stem-begin . stem-end) = Y'extent 
for up-pointing stems.  etc.  This also messed up pure heights.  For example: 
let's say that the user modified the stem-begin in the old master.  This would 
not have been taken into account for pure heights in certain situations.  
Furthermore, a modification of stem-end with a modification of length could 
result in one trumping the other in certain circumstances.  In general, when 
there are 4 properties (length, stem-begin, stem-end, and Y-extent) that 
represent one, and when three of these properties lead to bad pure heights, I 
think it is important to slim it down to one property (Y-extent).  To me, this 
seems less complex.  And, if the user wants to set length with the beginning at 
the note-head, stem::length is the appropriate function that will preserve pure 
heights (with my pure-closure patch, which I believe will be going on a 
countdown soon).

> On general principle I agree, but I believe that this patch simply
> brings the docs in line with actual git master.

Yes

> I assume that the
> examples about stem length currently just do nothing.

True

> As such, I
> think we should go ahead with it.
> 

Agreed.

> 32570e8ac85561afc1f59712301ee80c0d69d2b3
> The one-line summary doesn't mention anything about syntax
> changes, but the detailed commit message makes it clear.
> 

Yes.

> Moral of the story?  pay more attention to patch countdowns, I
> guess.

Agreed.

> I wouldn't be adverse to asking developers to clearly
> state a syntax change in the 50-character summary (although this
> gets tricky; maybe simply adding "(syntax)" would be ok?)... but
> at the end of the day, the patch went through the countdown.
> 

This I'll do from here on out.

Cheers,
MS




reply via email to

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