Re: Markup implementation

[David Kastrup]

Not finding a more suitable thread to hook onto.

Nicolas Sceaux <address@hidden> writes:

> 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.

How about letting markup be either, and markup lists are identified by
satisfying the list? predicate?  Seems simple enough.

> ==> 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 am currently working with the parser to have scalars possible to be a
number of different things if properly recognizable.  That would allow
wheezing music expressions into a number of things.  For example, it
would be reasonably easy to allow \tempo { c4. [c8 8] } = 56, and have
the tempo command haul any music it encounters through a simplified
rhythmic Staff (\tempoStaff ?) without staffline and in a proper size.

> 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.

I'd want that for markups that are not already scalars like integers,
strings, and similar, so that anything satisfying list? is interpreted
like a markup list, and everything else as what we call a "markup" so
far.

> 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.

I think with the changes I am currently plotting to the parser, changes
would remain rather confined.

-- 
David Kastrup