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

[Carl Sorensen]

On 5/2/10 8:38 PM, "Boris Shingarov" <address@hidden> wrote:

> 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.  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. 

Why do you think it will take 2x the time it took to write it?

I've reviewed the patch; the only problems I see are minor indentation and
formatting issues.  I'm surprised, because the patch set says it's 2 months
old, but I can't find any reference to issue 207105 in the -devel or the
-user archives.  So this is the first time I've known that the patch is
available for review.  If I've missed it, I'm sorry.
  
> For the bigger problems, like the
> "markup needs to know what's before and what's ahead", or for the
> integrated text/embedded-score flow, I don't know, could be up to 5x,
> and now we are suddenly looking at problems of user value, and all the
> repercussions.  

I don't agree with that assessment.  My observation is that the time need to
turn a solution into an acceptable patch is roughly constant.  So the
fraction of time spent on fixing things up is much less for a large patch
than for a small patch.

> So there is development happening which is important
> to users (= enables a serious academic publication through a top-name
> publisher), but those contributions can not be used better than just
> being thrown away by the community.

Absolutely.  I agree. 

I'll comment on your Rietveld patch.

Thanks,

Carl