On 2018/05/03 12:40:17, Carl wrote:
In my opinion, the most ideal result when one tries to create a new
context with
the same type and id of an existing context would be to generate an
error,
something like "Error: duplicate Staff with ID of A".
First, thanks for taking a look.
It seems impractical to eliminate ambiguity entirely, and probably
pretty difficult even to reduce it.
For one thing, context IDs are optional. I guess you wouldn't want to
start forbidding the creation of multiple staves without any ID, but
there is a choice to make.
There are features (\partcombine comes to mind, and << \\ >> IIRC) that
create contexts with specific IDs that are not necessarily unique in the
scope of a score. They can produce trees like
context-find-grandchild-ambiguous.ly. It would be nice to emit a
warning in that case. I wonder about the impact of an exhaustive search
on performance.
It might be interesting to experiment with forbidding creation of
* a context with the same type+ID as any of its ancestors
* siblings of the same type+ID
and see what happens to the regression tests. That might be worth
something, but unless the \change command were similarly limited, it
might still be possible to create weird trees by relocating branches.
(Note that when I say "it would be nice," I'm not volunteering to do
these things now.)
If we promise the behavior that your regression tests demonstrate,
then we have
developed an official scope for context IDs, and most LilyPond
constructs do not
have scope.
Could I address your concern with comments in the test descriptions?
Which ones? Even if we consider some of this behavior subject to
change, it's still useful to be able to detect changes.
https://codereview.appspot.com/348760043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
