lilypond-devel
[Top][All Lists]
Advanced

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

Re: Freezing for 2.18


From: Marc Hohl
Subject: Re: Freezing for 2.18
Date: Sun, 10 Mar 2013 21:15:12 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3

Am 10.03.2013 20:56, schrieb David Kastrup:
Marc Hohl <address@hidden> writes:

Am 10.03.2013 18:32, schrieb David Kastrup:
Ok folks, it is this time of the year again: I am trying to make myself
unpopular.

[...]

So I want to see 2.18 soon.  That means we need to stabilize work that
has already been done and cut down on experiments in the master branch.

Stabilizing means more or less accepting the current feature set, and
making sure it works as intended, is a useful combination of things,
does not offer interfaces which are sure not to survive into the next
stable version, and most of all, is properly documented to the user.
Um, what about the bar line interface in terms of recent discussions
on that topic? It looks as if the current interface is not seen as the
best choice, so it should be changed/improved before 2.18 is released.
I think there have been two issues crystallized out from it.

a) \bar "|:" and \bar ":|" are a frequent cause for surprise, and the
    return value one gets for dealing with that surprise, a direct way
    for specifying the desired look for the unbroken variant of the bar
    directly as \bar "|:.", is lost by having to explicitly define the
    broken behaviors as well with a defineBarType command before using
    \bar.  So changing the interface in a manner where one also defines
    the unbroken behavior explicitly rather than implicitly and thus get
    an easy way for aliases is desirable.

b) the defineBarType interface could be nicer

In 2.18, I'd like to see \bar "|:" work again.  And preferably I'd see
an interface for defineBarType that is expressive and natural enough
that we don't need to mess with it again as further needs develop.
Ok. I have some ideas and rough sketches about how the interface can be improved. I am not sure whether I can offer enough time to do the programming, but that's another issue. In a couple of days, I'll post my ideas about the new interface, once
they settled down in my head ;-)


I have been sketching out a rough time plan, but I am aware that it
might need some stretching in order to make everybody feel the code to
be in harmony with what we expect from a stable release.

So we need to get to decide how much we can reasonably fit into 2.18
nicely, and what work we can reasonably hope to be in shape in a
reasonable amount of time.  I don't have a hard answer for bar types
right now.  I want people to start thinking about those answers, of what
they consider reasonable to bring into a fine shape until release, and
how to deal with those issues that won't fit a time frame suitable for a
release in several months.
Of course. I think that the bar line interface has to be discussed
thoroughly on -devel even before programming work starts.





reply via email to

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