lilypond-devel
[Top][All Lists]
Advanced

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

Re: Freezing for 2.18


From: David Kastrup
Subject: Re: Freezing for 2.18
Date: Sun, 10 Mar 2013 20:56:46 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

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.

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.

-- 
David Kastrup




reply via email to

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