[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Rename \markuplines to \markuplist (before running convert-ly) (issu
From: |
address@hidden |
Subject: |
Re: Rename \markuplines to \markuplist (before running convert-ly) (issue 5312050) |
Date: |
Mon, 24 Oct 2011 08:27:27 +0200 |
On Oct 23, 2011, at 11:26 PM, address@hidden wrote:
> Reviewers: Bertrand Bordage,
>
> Message:
> On 2011/10/23 21:08:09, Bertrand Bordage wrote:
>> LGTM. You'll be happy to know that Mike and I are currently trying to
> get rid
>> of \markuplines, so that there will only be a \markup command.
>
> No, I am not happy, since for example fret markings in tabulatures are a
> perfect match for markup lists (and calling them markuplines is quite
> obscuring this wonderful way of defining them).
The idea is not to get rid of the functionality, but rather the nomenclatural
distinction. The problem is that, in LilyPond markup-speak, there is not a
clear division between creating content, shaping content, and laying content
out. Markups commands like \simple, \note etc. deal with either the creation
of content. \italic, \bold etc. deal with its shaping. And \justify, \line
deal with its layout on the page. markuplist (née markuplist) is a particular
manifestation of this problem on the page level that implements something not
unlike Java Swing's box layout (fancier because it allows for page breaks).
But one could imagine a host of layout managers that deal with the layout of
markups (and scores) on the page, and it would not be a good idea to hardcode
these into the parser (markuphorizontallist,
markuplistexceptwhenmarkupislargerthanthreecentimeterswideinwhichcaseitshouldnotbealist,
etc. as commands). Rather, \markup should be the only command in the game,
and all of the layout managers should be declared within the markup bloc.
It seems like a good representation of any markup, be it top-level or in a text
script, would be a Prob that has three variables:
SCM layout_manager_
vector<SCM> transformations_
vector<SCM> elements_
\markup { \column { \italic foo bar }} would use line as its layout manager and
have two elements, one markup that used nothing as its layout manager (markups
with 1 element cannot have layout managers) and had no transformations and one
markup that used nothing as its layout manger and had an italic transformation.
In this representation, box-layout-across-pages could be a layout manager that
works like markuplines. The page breaker would take all top level markups,
check the layout managers, and automatically create chunks based on the layout
manager being used.
Cheers,
MS