[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RemoveEmptyStaffContext erases previous setting
From: |
Mats Bengtsson |
Subject: |
Re: RemoveEmptyStaffContext erases previous setting |
Date: |
Mon, 08 Feb 2010 16:24:57 +0100 |
User-agent: |
Internet Messaging Program (IMP) H3 (4.0.5) |
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-----