lilypond-devel
[Top][All Lists]
Advanced

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

Re: Add changes entry for Mike's work on skylines. (issue 8613043)


From: dak
Subject: Re: Add changes entry for Mike's work on skylines. (issue 8613043)
Date: Tue, 16 Apr 2013 07:51:47 +0000

On 2013/04/16 07:40:19, Trevor Daniels wrote:
On 2013/04/16 07:20:59, dak wrote:
> On 2013/04/16 06:05:42, MikeSol wrote:
>> I would add a note that, if there is too-snug spacing
>> for an object, setting its vertical skylines to #'()
>> will generally restore old behavior.
>
> I am not really enthused about telling people that,
> since "too snug" is a bug and needs to get fixed rather
> than worked around.  We'll get a proliferation of
> LilyPond sources irretrievably tied into the bugs of
> particular versions if we tell people to work around
> bugs rather than report them.

Indeed.  That is why we do not document bugs or add
workarounds to the documentation (with a few exceptions,
usually when it is agreed a fix is most unlikely to
materialise, e.g. the grace timing problem.)  Bugs (and
their workarounds) should be recorded in the Bug DB.

I hate it when I get last-minute realizations.  Here is another thing we
need to do for the stable release: go through all problems of the "too
snug" kind and work out defaults that avoid them.  It's ok to tell
people in our documentation how to get stuff move closer in case of
necessity, but if we aren't talking about running text and similar
things, looser spacing than necessary is _not_ a bug.

Closer spacing than appropriate _is_ a bug.  One can publish a score
with loose spacing, but one can't publish a score where things are
sitting on each other.

So for a stable release, we need conservative settings.  Settings that
won't _force_ people to pepper their sources with overrides and tweaks
just to throw them all out again when the next version arrives.

https://codereview.appspot.com/8613043/



reply via email to

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