Issue 1650: Multiple header blocks shall be merged rather than replace a previous one

Issue 1650: Multiple header blocks shall be merged rather than replace a previous one

If there are two or more header blocks at top-, book-, bookpart- or score-level,
the settings of all header blocks are merged. If a value appears in multiple
blocks, the last assigment wins.

Deprecated by issue 6445053

[dak, 2012-07-27 05:09:22]

http://codereview.appspot.com/6441058/diff/1/lily/parser.yy
File lily/parser.yy (right):

http://codereview.appspot.com/6441058/diff/1/lily/parser.yy#newcode932
lily/parser.yy:932: /* Copy the new header fields, i.e. overwrite existing, but
preserve unchanged ones */
I think this is the wrong way to do things since you can't refer to old header
values when defining the new one.  Instead, you should start with the definition
you are adding things to, like LAYOUT and similar do.  So that likely means that
you need to change the definition of lilypond_header (or create several versions
of it) to make it not start from an empty slate.

[dak, 2012-07-27 05:10:50]

On 2012/07/27 05:09:22, dak wrote:
> http://codereview.appspot.com/6441058/diff/1/lily/parser.yy
> File lily/parser.yy (right):
> 
> http://codereview.appspot.com/6441058/diff/1/lily/parser.yy#newcode932
> lily/parser.yy:932: /* Copy the new header fields, i.e. overwrite existing,
but
> preserve unchanged ones */
> I think this is the wrong way to do things since you can't refer to old header
> values when defining the new one.  Instead, you should start with the
definition
> you are adding things to, like LAYOUT and similar do.  So that likely means
that
> you need to change the definition of lilypond_header (or create several
versions
> of it) to make it not start from an empty slate.

Actually, it looks like it just doing that: taking the old value and adding to
it.  So what it the problem you are trying to cure here?

[Reinhold, 2012-07-27 11:02:16]

On 2012/07/27 05:10:50, dak wrote:
> > I think this is the wrong way to do things since you can't refer to old
header
> > values when defining the new one.  Instead, you should start with the
> definition
> > you are adding things to, like LAYOUT and similar do.  So that likely means
> that
> > you need to change the definition of lilypond_header (or create several
> versions
> > of it) to make it not start from an empty slate.
> 
> Actually, it looks like it just doing that: taking the old value and adding to
> it.


Apparently, it doesn't do it properly:

\book {
 \header { title = "Title" }
 \header { composer = "Composer"  }
 \score { \new Staff { c'4 } }
}

or

\version "2.15.42"
\score {
  \new Staff { c'4 }
  \header {  piece = "Piece"  opus = "Opus" }
  % This should NOT clear the piece from above:
  \header { opus = "New Opus" }
}

In both cases the assignments of the first header block are lost, because when
parsing the second header block, it starts from an empty block and replaces the
whole header block rather than adding to the existing assignments...

The hierarchy works correctly (i.e. top-level header blocks are used as base for
book-level blocks, which are used as base for bookpart-level blocks, which are
used as base for score-level blocks), mainly because in score.cc and book.cc the
parent's header block is copied when inserting a book or score into its parent.

[dak, 2012-07-28 08:01:50]

http://codereview.appspot.com/6441058/diff/1/lily/parser.yy
File lily/parser.yy (right):

http://codereview.appspot.com/6441058/diff/1/lily/parser.yy#newcode993
lily/parser.yy:993: /* Copy the new header fields, i.e. overwrite existing, but
preserve unchanged ones */
The problem with this approach is that bookparts are initialized from
$defaultheader.  That means if you have something like
\header { title = "global" }
\book { title = "book" \bookpart { piece = "whatever" ...
Then the \bookpart will have an effective title of "global".