David Kastrup <d...@gnu.org> writes:
> "Phil Holmes" <m...@philholmes.net> writes:
>
>> Surely this points to the pop operation in \override as being at
>> fault? If \override was simply push, rather than pop-push then the
>> code above would seem to work as intended.
>
> Sure. The idea presumably was not to have stack buildup from things
> like
>
> \voiceOne c c \voiceTwo d d \voiceThree c c
It would appear that this behavior was implemented in lily/parser.yy with
commit 39dd20959c8b3a143cfe41138a5c62749da54079
Author: Han-Wen Nienhuys <han...@xs4all.nl>
Date: Mon Oct 17 00:04:45 2005 +0000
* input/regression/override-nest.ly: new file.
* python/convertrules.py (FatalConversionError.subber): conversion
rule for #'callbacks
* input/regression/override-nest.ly: new function.
* lily/parser.yy (music_property_def): allow \override #'a #'b =
#c too.
* lily/context-property.cc (lookup_nested_property): new function.
(evict_from_alist): new function.
(general_pushpop_property): new function.
(execute_general_pushpop_property): rewrite. Support nested
properties too.
There is no rationale for this change to be found in the patch, patch
description or changelog entry. There is no rationale to be found on
the developer list close to that date.
But while searching there, finding
<URL:http://lists.gnu.org/archive/html/lilypond-devel/2005-10/msg00004.html>
was amusing. Some things stay the same all over.
--
David Kastrup
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
