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).
_______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel