Rename \markuplines to \markuplist (before running convert-ly)

Rename \markuplines to \markuplist (before running convert-ly)

This inconsistency has been annoying me for years.  Don't forget to
run scripts/auxiliar/update-with-convert-ly in input/regression and
Documentation before doing the checks.

[Bertrand Bordage, 2011-10-23 21:08:09]

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.

[dak, 2011-10-23 21:26:18]

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).

[mike_apollinemike.com, 2011-10-24 06:27:32]

On Oct 23, 2011, at 11:26 PM, dak@gnu.org 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