lilypond-devel
[Top][All Lists]
Advanced

[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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]