Re: RemoveEmptyStaffContext erases previous setting

[Mats Bengtsson]

Quoting Reinhold Kainhofer <address@hidden>:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Friday 05 February 2010 18:20:23 Mats Bengtsson wrote:
> > On the other hand, \RemoveEmptyStaffContext is a variable containing a
> > full list of settings, which replace the current list of settings for a
> > Staff context.
>
> Yes, that's the problem. The real solution would be to change it to some kind
> of function/macro, which is not evaluated when it is defined but 
> rather when it
> is called. That way it would modify the current Staff context and not reset
> Staff to the default state during startup.

Would there be any disadvantages to replace Axis_group_engraver by 
Hara_kiri_engraver in the default definition of Staff, and just use
\override VerticalAxisGroup #'remove-empty = ##t or ##f to switch 
between ordinary and RemoveEmpty versions? Is the book-keeping overhead 
in the Hara_kiri_engraver so large that it would increase the 
computational time significantly or could there be any other 
disadvantages. The only other difference in RemoveEmptyStaffContext can 
be removed, according to 
http://code.google.com/p/lilypond/issues/detail?id=879.

This should be a much simpler solution than trying to fiddle with 
advanced Scheme stuff to work around limitations in the syntax.

> > A pedagogical problem is that the syntax looks the same in both cases,
> > but what really happens is fundamentally different. Apart from the
> > warning in the manual, mentioned above, the only way to know if
> > \layout{
> >   \SomeName
> >   ...
> >
> > will do one or the other, is to look in the file
> > .../ly/engraver-init.ly and see if \SomeName is defined as a variable
> > or if it's the name of a context.
> [...]
> > If would be pedagogically simpler to realize this difference if the
> > syntax was separate if you define a context from scratch (as is the
> > case with \RemoveEmptyStaffContext) or if it's defined by adding onto
> > an existing context.
>
> That's just fighting the symptoms, but not the cause. The cause is that there
> is no wayto store a group of context modifications for later application
> without storing the whole context (thus resetting all other settings).

I still think it's relevant to have a syntax difference between
- Copy the current definition of context type Foo
- Take settings from a variable called Foo
Currently, \context{\Foo} means one thing if Foo is the name of a 
context and another thing if it's the name of a variable (I dare not 
even guess what LilyPond does if it's both).

   /Mats

> - --
> - ------------------------------------------------------------------
> Reinhold Kainhofer, Vienna University of Technology, Austria
> email: address@hidden, http://reinhold.kainhofer.com/
> * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/
> * Edition Kainhofer Music Publishing, http://www.edition-kainhofer.com/
> * LilyPond music typesetting software, http://www.lilypond.org/
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAktwGbAACgkQTqjEwhXvPN1CzwCgshp2iapre3MjlgLYQZDmrCu4
> sWsAoMoMYfIXgnHbfTyXPvR/94Fflggk
> =VUDJ
> -----END PGP SIGNATURE-----