Graham Percival <graham <at> percival-music.ca> writes:
> This is a
> problem for projects such as mutopia – a large fraction of their
> .ly files don’t compile with current lilypond. That means that
> they can’t benefit from recent bugfixes; users wanting the sheet
> music in a different size (say, printing a choral score as an A5
> booklet) must delve into the ly code and make manual changes.
>
I recently updated a fairly complex piece from 2004 on mutopiaproject.
Convert-ly turned it into valid input for current LilyPond, but none
of the \overrides did what was intended. Nearly all of them were no
longer necessary due to bug-fixes in the past six years.
> 2. Define a subset of input as being stable for the 3.x branch.
> We add regression tests for that subset of notation and
> forbid running convert-ly on those files.
Why forbid convert-ly? Is the idea to freeze the syntax that many
users have already committed to memory ?
> At the moment, I
> imagine that the subset would consist of at most Notation
> sections 1.1 Pitches, 1.2 Rhythms, and the overall file
> organization; nothing else. Changes to input other than that
> subset are fine.
>
If you mean the portions of these sections that users have likely
committed to memory, that should work.
These sections also cover recently-added features like auto-beaming
overrides, and modal transformations, which might someday be improved
with a syntax change that convert-ly could handle.
> In greater detail: I’m suggesting that we have a round of syntax
> stabilization (GLISS). At the end of it (3 months? 6 months?), we
> add a few regression tests that might look something like this:
Having the currently-frozen syntax be un-frozen and then re-frozen
six months later might lead to changes that we regret. But if it is
the core notation in a set of regression tests that is to be frozen,
that should work.
There are some GLISS topics that would take longer to get right, such as:
+ whether we should implement {c4 d e f}*4 to repeat a sequence
+ whether to disallow some unusual syntax that Lilypond currently
allows, but which prevents LilyPond from recognizing numbers in variable
names.
Such changes would affect what is allowed in the notation covered by
Pitches and Rhythms, but would not affect the "forseeable usage" core
notation as preserved in those regression tests.
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
