On 2011/11/03 11:45:00, Reinhold wrote:
http://codereview.appspot.com/5322065/diff/3001/input/regression/complex-once.ly
File input/regression/complex-once.ly (right):
http://codereview.appspot.com/5322065/diff/3001/input/regression/complex-once.ly#newcode11
input/regression/complex-once.ly:11: \unHideNotes g a
\once\hideNotes b c |
While this is the easy approach, it builds on the fact that hideNotes
is
internally implemented as a music expression with several \override
commands. If
that internal representation ever changes, we won't have a proper
regtest any
more...
I would prefer to define the multiple property operations command
explicitly in
the regtest, so we have complete control and no risk that a totally
unrelated
change might break a regtest (without us even noticing).
I.e. I would explicitly do
multipleOperations = {
\override #'NoteHead #'color = #red
\override #'Stem #'color = #blue
}
and then \once\multipleOperations.
I disagree. The whole point of redefining \once is to make it useful
for _existing_ functions/variables known to work by meddling with
properties.
Regtests also serve as illustrations of functionality. Defining an
explicit sandbox for the regtest to work on is completely eliminating
its educational value.
I consider it very unlikely that changing \hideNotes in a manner where
it would either
a) work with the previous definition of \once
b) keep working with the new definition of \once while failing to work
with a sandbox like the above
is feasible at all.
So I consider the regtest as _fully_ doing its intended job. The whole
point of the change is that you can use \once on existing commands like
\hideNotes. That's the desired and intended behavior.
http://codereview.appspot.com/5322065/
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
