Re: Freezing for 2.18

[David Kastrup]

Xavier Scheuer <address@hidden> writes:

> On 10 March 2013 20:56, David Kastrup <address@hidden> wrote:
>>
>> 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.
>
> It is not _that_ frequent!
> First, the manual clearly states that repeated section are better
> entered using \repeat volta commands.

Sure.

> Second, there is a convert-ly rule that takes care of that very
> nicely.

Correct for existing code, though it would seem that a non-trivial
amount of users does not think of using convert-ly.

> Third, the new barline interface is/was already a great improvement
> compared to 2.16.  It helped several users on the French users mailing
> list who without it would not have been able to have the barlines they
> wanted how they wanted.

Reverting it was never an issue.  At any rate, the "|:" discussion
turned up a few use cases where the strict equivalence of recipe and
\bar string led to rather appalling \bar strings.

If a refined interface can defuse these cases as well, it would
certainly seem like a good step to take.

> That being said, probably it can still be improved.  But I would like
> to thank first the people who worked on it because it was really nice.

I can certainly agree to that.  To be able to see blemishes, one needs
to start with a nice background, after all.

> Speaking of "frequent cause for surprise" I think the change between #
> and $ in music functions or the change of "event chord" (or something)
> breaking existing codes and snippets from the LSR beats by far this
> "barline issue".

Well, the question is always the balance between gain and pain.  Where
the pain is not an immediate consequence of the gain but rather a
byproduct, there is no point in being fatalistic about not working on
further improvements.

The change of # and $ unified the behavior of # and $ in- and outside of
#{ ... #} so that one can actually copy&paste in- and outside code
without surprises.  That's a significant gain.

The event chord changes were definitely a nuisance, but it meant that
music functions inside of chords did not need special casing any more,
it meant that repeat chords could be made to work reliably in connection
with \relative, and it meant a closer correspondence of internal and
external representation.  Further side effects were that string number
indications and something else started working on single notes.

That does not mean that any problems in that area should get swept under
the rug.  Nothing is good enough that it can't be further improved, and
that it was worse at some point of time is no reason for further
improvement.

> And since IIRC these are both 2.17 "improvements",

No, event chord changes were in 2.16 (and yes, they definitely made for
most of the headaches in moving LSR forward), $/# the same (those made
for rather few headaches actually, since convert-ly was rather good at
doing the right thing).

So damage control for those is done.  I definitely agree that at least
the event chord changes were causing a lot more trouble than the bar
line interface likely ever could.  But that's not because the execution
could have been improved (that might have been possible independently in
some aspects), but because the resulting pain was an immediate and
unavoidable consequence of the gains and not separable from it, because
the gain was based on a change of internal representation.

> I expect "surprises" from users to come frequently again when 2.18
> will be released.

No, those are over.  We'll have our fair share of surprises for 2.18 as
well, but that does not mean that we should not strive for the best 2.18
we can deliver while the game is still on.

-- 
David Kastrup