Re: markup-command and markup-command-list signatures

[David Kastrup]

"Boris Shingarov" <address@hidden> writes:

> I am working on a system of markups which allows to specify more
> flexible formatting rules.  WE are using it for things like multi-line
> embedded scores, mixing them with markup lines, rules about what
> things / combinations of things should not start / end a line, also
> there are rules like "no line break between certain words and
> beginning ebmbedded score", that kind of formatting rules.  I had
> described some of these ideas in my earlier posts on this list. 
> Markup functions being able to return a list of stencils.

Markup lists don't do the trick here?

>   Much more importantly, markups need to be aware of what was placed
> before, and what is to follow, therefore when processing the
> markup-list, we need to pass a continuation at each step, instead of
> iterating over the list.  This kind of ideas.    It even sort of
> works.  Well, works enough for production use by non-programmer
> users.  But still far from being a general Lilypond improvement.  The
> other, easier improvements (orphan-avoiding functionality,
> page-breaking fixes), are making it fine into the upstream repo: for
> those, going from the happy state of having the user's problem fixed,
> to the happier state of fixing it for everyone, is of a reasonable
> proportion compared to the whole amount of work.   But with my markup
> changes, it's much different.  Even the first and simplest of these
> changes (patch 207105), to go from the current state to an actual
> submittable patch, will take like 2x the time it took to get it to
> solve the user's probem.

I don't see that you stand a chance with the standard processes here.
You don't have commit access.  The gold standard here (to the exclusion
of all other workflows) is a patch review on Rietveld.  That basically
limits feedback to persons with a Google developer account.  At the
point of acceptance, the change is pulled in as a single commit touching
lots of areas simultanously.  Since mainline development continues,
there is no sensible strategy for merging/rebasing for anybody without a
branch history.  So the only person able to work on this will be
yourself.  People will be able to check your work only when the patch
set applies.  But that means that mainline changes in the same areas
need to be tracked by you and will also pollute the Rietveld review
area.

I don't see that a task like this can be sensibly done except in a
separate branch.  But working like that is a git workflow rather than a
Subversion one, and does not fit with the Rietveld processes.  Of course
you can set up your own Lilypond repository for pulling, but the way I
see it, the relevant developers would refuse to participate in
"non-standard" processes like that.

I don't see that humongous changes like that can be usefully integrated
in a single non-merge commit.  There must be infrastructure changes and
so on, and you'll need to set up reviews for each of them, without an
apparent goal being accomplished before the last commits make it.

Basically you'll be on your own going against the tide until you are
finished.  The work flows here are designed to achieve code quality by
making it harder for a would-be contributor to get sub-par code through,
not by making others participate with the work.

I'd like to see me proven wrong.

-- 
David Kastrup