lilypond-devel
[Top][All Lists]
Advanced

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

2.18 schedule/incoming issues


From: David Kastrup
Subject: 2.18 schedule/incoming issues
Date: Sat, 12 Oct 2013 18:12:37 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

Ok folks, I am currently swamped: we recently had an influx of
near-trivial documentation bugs/requests that would warrant attention.
There are also smaller bits and pieces, but here is the beef on the 2.18
situation:

There are quite few issues left that need to be dealt with consistently
before 2.18.

One that I can think of is bringing \fill-line into a consistent state
with the rest of the spacing.  Which will likely necessitate some
followup work on our uses of it, but not all that much as far as I can
see at a glance.  Branching off 2.18 does not need to wait for that as
far as I am concerned, and the current description of it is vague enough
that it would still more or less fit.  Less work for the translators,
but ugh.

We have an issue (or actually several conflicting issues) centered
around Completion_*_engraver.  If we can get something upward-compatible
to the current behavior in (I proposed something but have not got around
to implementing it myself), it should be reasonably fine for inclusion:
at least the default behavior has then been around for a long while
without a lot of complaints.  Again, this is specialized enough that
it's not much of an issue if there is no translation available for the
exact state of the issue.  Neither will it be much of an issue if it
does not get included in 2.18, but some people might be unhappy.

We have an inflow of several issues daily of things that are partly easy
to fix.  I'd be quite grateful if some people took a look at some of
them.  If I do git shortlog -n --since "1 month ago", this starts with

David Kastrup (51):
      Add regtest for slurs in connection with omitted beams in tablature
      Issue 3542: Manual beaming corrupts slur placement in tablature
      Issue 3297: Make lexer more robust against unexpected EOF in main input
      Issue 3554: Avoid empty grammar rules using @$ for getting a source locati
      Issue 3552: Don't modify lists returned by markup list functions in interp
      Issue 3547: Allow identifiers or scheme expressions evaluating to music af
      Issue 3545: Obsolete "Accordion-discant symbols" snippet
      Run scripts/auxiliar/makelsr.py
      Add entry for accordion registers in Documentation/changes.tely
      Issue 3541: Fix snippet positioning-multi-measure-rests.ly
      Run scripts/auxiliar/makelsr.py
      Issue 3558: lilymidi: format time signature and tempo better.
      Issue 3555: Parse context definitions and context modifications in \notemo
      convert-ly rule for simplifying \stringTuning
      Run scripts/auxiliar/update-with-convert-ly.sh
      Issue 3553/1: get_default_interpreter should create contexts with missing 
      Issue 3553/2: When creating a hierarchy above Bottom, all intermediate lev
      Issue 3292/1: Changes entry for changed \defaultchild behavior (issue 3225
      Issue 3292/2: Add \defaultchild rule for convert-ly
      Simulate having run scripts/update-with-convert-ly.sh for 2.17.14
      Issue 3563: Allow define-*-function to accept currying definitions
      Issue 3564: Doc, EG: Add more information about markup (list) commands
      Issue 3565: Doc, EG: LilyPond's getting too smart for the "Inline Scheme c
      Issue3571: Stop \lyricmode { \skip 1.*3 } from failing.
      Issue 3582: Let make-music accept existing music or alists as source
      Use make-music with music arguments
      Issue 3580: Replace unwarranted uses of map with for-each and other Scheme
      Issue 3579: Make "Adding extra fingering with scheme" snippet do something
      Run scripts/auxiliar/makelsr.py
      Issue 3573: Calculate wordwrapped/justified lines using the stencil stacki
      Issue 1939: showLastLength with hidden tie error message
      Issue 3588: Track move of grammar to CG (issue 3015) in German translation
      Issue 3584: Let convert-ly -d reflect last effective rather than last appl
      LSR reimport because of issue 3584 changing version numbers
      Issue 3566: Grace notes should be autobeamed
      Add Grace_auto_beam_engraver to default engravers for Voice
      Add one-time convert-ly rule for grace beaming
      Run scripts/auxiliar/update-with-convert-ly.sh
      Revert "Add one-time convert-ly rule for grace beaming"
      Manually revert bad convert-ly change for input/regression/lyric-combine.l
      Add reference to Grace_auto_beam_engraver to Notation/Rhythms
      Add regtest for Grace_auto_beam_engraver
      Issue 2931: Allow non-LilyPond identifiers like "violin1" to be called as 
      Add regtest for quoted identifiers
      Change option description -x,--long-option to -x, --long-option consistent
      Remove unused data from Completion_heads_engraver and Completion_rest_engr
      Issue 3593: Announce ends of ties in Completion_heads_engraver
      Issue 3115: Revert "Uses a heuristic to determine if chord tremolos collid
      Issue 3604: Fix function signature of overrideTimeSignatureSettings
      Issue 3600: Grob `SustainPedal' has no interface for property `direction'
      Issue 3572: convert-ly should produce several backup files for each invoka

So you can see that there are a lot of _different_ issues (not just
dozens of commits all for the same thing), quite a few of them
non-trivial, that I've been juggling on in the last month.

Now it turns out that in the course of smart key signatures and
transposing, I wrote some very nice interfaces and sample code, and the
parser balks at it, getting optional arguments wrong.  This means that I
am currently extensively documenting the design of the function argument
parsing and making sure that the design and the implementation match.
They actually mismatch to a degree that I have trouble understanding why
as much works as it currently does.

At any rate, this is the part in the parser that is _really_, _really_
hard.  So I can't really juggle ten other things while thinking about it
(and actually, I have quite a bad common cold for about a week already
which does not help), and the near-trivial issues keep piling on.

If I branch 2.18, and then don't focus on merging/solving trivial
issues, 2.18 and easy fixes for it will run apart and require a solid
bout of merge work later for getting 2.18 as good as it can be.  So I am
procrastinating on the branch-off in order to save myself from
merge-work later.

That's also not good.  At any rate, the parser problems need to get
fixed: they are bad.  And so that's what I'm currently doing.  I've
documented the logic the function argument parsing needs to match and am
bringing design and code into line with that.

-- 
David Kastrup



reply via email to

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