lilypond-devel
[Top][All Lists]
Advanced

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

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


From: Boris Shingarov
Subject: Re: markup-command and markup-command-list signatures
Date: Sun, 02 May 2010 22:38:25 -0400
User-agent: Webmail 5.0

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.  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.  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.  I remember reading on the LKML,
kernel guys having somewhat similar problems with vendor patches and
integration with the vanilla tree.  I don't (yet) know how we should
deal with this, just thinking aloud while there is this discussion
about the same area of code...
 
> that is, any number of scheme arguments, then any number of single markup
 > > arguments, then any number of markup-list arguments, even though I don't
 > > know if having several markup list arguments is useful or not
(and if it's
 > > doable).

 





reply via email to

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