Markup implementation

[Nicolas Sceaux]

Le 17 sept. 2011 à 17:41, address@hidden a écrit :
> 
> I've been toying with the idea for some time now of making markups at all 
> levels behave more like grobs.  It would require a massive code rewrite, but 
> it'd allow a much more uniform approach to exactly this sort of thing 
> (markups could, for example, issue errors like grobs, which gives the user 
> the place in the code where the bad markup is).  It'd also allow for some 
> code-duping in the footnote code to go away and would allow for 
> object-oriented references between markups (which would help with spacing, 
> advanced inter-markup communication for layout stuff, etc.).
> 
> Would anyone be interested in co-taking this on?

Hi Mike,

Just writing quickly, I hope I don't write nonsense.

I see several problems wrt to markups:

1) the markup / markup-list duality sucks.  I tend to implement every
markup command twice (with its markup-lines counterparts).

==> markup and markuplines should be unified, somewhat.

2) For toplevel markups, there is no way to change the padding or spacing
of a single markup.  This is only possible globally at \paper level.
Some markups need to be attached to the score before, some to the score
after, other should stick together (away from surrounding scores), etc.

==> it shall be possible to set some characteristics to toplevel markups
(e.g. before/after padding and spacing stuff.)

3) mixing several lines of text and music in a single paragraph is just
not possible.  One or two years ago, someone provided an implementation
sketch, where a markup is given some extra context when interpreted, to
figure out where on the current line it appears.
I'm sorry I can't remember his name.
This may be the inter-markup communication thing you're talking about?

Currently, the internal representation of a markup is a simple list:
  (markup-command arg1 arg2 ...)
And a markup a interpreted by applying the markup-command on the args
(plus the layout and properties special arguments).
This is not expressive enough.  A more elaborate data structure shall
be used.

A first step could be to move the internal representation of markups to
C++, like grobs, music expressions, etc, with similar accessors.  At this
point the functionnality would be unchanged.  Then we could add some
logics to deal with the mentionned problems.
But this pass most probably leads to backward incompatibility at some
point.

Nicolas