Not finding a more suitable thread to hook onto.
Nicolas Sceaux <nicolas.sce...@gmail.com> writes:
> Le 17 sept. 2011 à 17:41, m...@apollinemike.com 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
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
