Le 17 févr. 2010 à 07:27, Boris Shingarov a écrit : > Another change I was thinking about, is to redesign the API contracts > around interpret-markup-list. [...]
Boris, The patch you submitted seems to me as a hack making the \score markup command behaving differently from other markup commands, and breaking the current protocol in which the distinction between markup/stencil and markup-list/stencil-list is clearly made. For instance, currently we have \column and \column-lines \justified and \justified-lines so in that context the natural solution for the \score issue would be \score making one stencil for all systems and e.g. \score-lines making one stencil per systems So the patch you proposed cannot be accepted (afaic) in its current form. However, I think you're right when you say that this protocol should probably be redesigned, in order to tackle several issues: - we indeed certainly want to get rid off the dual definitions of \column vs \column-lines, etc, ie. merge the markup and markup-list things, so that "the right thing" happens without having to care about it; - the current internal representation of markups (bare lists of markup commands and their arguments) is not very expressive. By using a more complexe data type, some extra information may be added to the markups. For instance, you cannot add attach a \label inside a piece of text, instead you have to stop the \markup(lines) block, add a label, and start a new \markup(lines) block. An other example: you cannot change the after-title-spacing &co settings attached to a particular toplevel markup; - the point you made about keeping a context across stencil interpretations is interesting. Nicolas _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
