On Oct 1, 2011, at 12:48 PM, David Kastrup wrote: > "m...@apollinemike.com" <m...@apollinemike.com> writes: > >> Hey all, >> >> Just a note to letchya'll know that there'll be 7(ish) people >> attending Extreme Makeover: Markup Edition in Paris over the weekend >> of the 15th. The idea is to make the behavior of markups more robust >> (likely by treating them like objects (not in the pejorative sense of >> the term "treating like objects"...the CS sense) instead of a set of >> instructions to be fed to stencils). This will likely touch >> everything, from the parser/lexer to perhaps "Engravers" for markups >> (i.e. Line_markup_engraver) to refashioning code in Pango to whatever. >> >> We'll have Skype open for the duration of coding hours for those who >> want to participate à distance, but if any of you would like to chime >> in on markups before this weekend, please do! > > I am actually just working on the syntax to make markups (more > precisely: any scalar) acceptable as the last argument of type Scheme > (namely non-specific) to music functions and their ilk. > > The principal motivation is being able to convert \mark with its current > semantics into a music function as well, and of course be able to > harvest this increased kind of flexibility of the final argument for > user-defined functions. > > While I don't expect much overlap in our endeavors (I don't actually > look inside markups for mine), it is likely that you'll get merge > conflicts on any patches based on material of mine. > > I've also considered adding define-markup-function (in analogy to the > existing define-*-function commands). It would be orthogonal to the > existing define-markup-command in that the latter works only _inside_ of > markups, while the former works _outside_ of markups. > > I've not yet seen an existing application clamoring for this, so I have > not yet bothered. It would be reasonably simple to do, however. >
All is good - I can't imagine us changing the input syntax, so like you say, there shouldn't be many merge conflicts. Cheers, MS _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel