[prev in list] [next in list] [prev in thread] [next in thread] 

List:       lilypond-bug
Subject:    Re: extenders over bar lines in 2.19.55 [was: Automatic Lyric Extenders]
From:       Alexander Kobel <a-kobel () a-kobel ! de>
Date:       2017-02-21 15:40:48
Message-ID: 0c0f0651-f88d-802d-1f74-7dec12361a44 () a-kobel ! de
[Download RAW message or body]

Hi David, hi all,

On 2017-02-19 15:58, David Kastrup wrote:
> Michael Gerdau <mgd@qata.de> writes:
> 
> > Am 18.02.2017 um 21:15 schrieb Alexander Kobel:
> > > [Bug report summary:]
> > > 
> > > Extenders are not drawn anymore for melismata that include notes that
> > > are not bar-aligned, starting somewhere between 2.19.50 and 2.19.55.
> > > M(N)WE attached - the first and second score should have extenders until
> > > the last note.
> > 
> > I've tried this on 2.19.50 - 2.19.55 and it seems as if it used to work
> > until 2.19.54, i.e. apparently it is a 2.19.55 regression (which kind of
> > explains why I had not seen this problem before :) )
> > 
> > The first example has an extender only because the default minimum
> > length is 1.5. if that is reduced to 0 that extender vanishes altogether
> > in 2.19.55.
> 
> This is a consequence of
> 
> commit 6c6d1f6ac9e6a7a9aba760dcbb41b4fbbc8f0536
> Author: David Kastrup <dak@gnu.org>
> Date:   Sat Feb 4 14:43:47 2017 +0100
> 
> Issue 5053/2: Fix extendersOverRests property
> 
> This previously behaved as always-on.

Argh, sure.  Should have thought about that after the earlier, similar report from \
2017-02-15...

> This program part now works as intended.  Unfortunately,
> extendersOverRests appears to be a misnomed property, so the resulting
> effective change from extendersOverRest being interpreted as ##t
> regardless of its setting to having it default to ##f affects more than
> extenders over rests.

Not sure about the original intention.  I see the point for having the choice to stop \
extenders over rests (as the documentation suggests).  The "side effects" are hardly \
what I expect, and I don't immediately see a use for that.

> Maybe one should let the setting default to ##t for now and try matching
> its documentation to its behavior before changing the default back to
> ##f.

+1.  Right now, the cure seems to do more harm than good, at least from a user's \
point of view... Concerning "matching doc to behavior": do you intend to change \
rather docs, behavior, or both?


On a somewhat, but not quite, unrelated note, concerning \
https://sourceforge.net/p/testlilyissues/issues/4509/ and \
https://codereview.appspot.com/313240043: Do you want/need any input there, or are \
you merely keeping a log of your pondering?  I feel somewhat involved as Knut's and \
your "Rietveld proxy", but I'm not sure whether or how I can assist.  (Note: I don't \
intend to push by any means; I've got a wagonload of way more important things to \
deal with these days...)


Cheers,
Alexander

_______________________________________________
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond


[prev in list] [next in list] [prev in thread] [next in thread]