[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Markup and markup-list protocol
From: |
Nicolas Sceaux |
Subject: |
Markup and markup-list protocol |
Date: |
Fri, 19 Feb 2010 21:04:42 +0100 |
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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Markup and markup-list protocol,
Nicolas Sceaux <=