Re: Update on the coding par-tay

[address@hidden]

On Oct 1, 2011, at 12:48 PM, David Kastrup wrote:

> "address@hidden" <address@hidden> 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