bug-lilypond
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Change_iterator refuses to move a NullVoice into a Staff


From: David Kastrup
Subject: Re: Change_iterator refuses to move a NullVoice into a Staff
Date: Wed, 05 Apr 2017 11:03:14 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux)

Dan Eble <address@hidden> writes:

> %{
> NullVoice is unlike a Voice in this respect: trying to move it to a
> different Staff with \change fails with this warning:
>
>     Change_iterator::process (): NullVoice = `soprano': 
>     cannot change `Staff' to `S': not changing to same context type: Staff
>
> Apart from the warning, this is inconvenient.  The NullVoice remaining
> in the original staff keeps the original staff alive, demanding manual
> work to make it disappear.
>
> The NullVoice context definition contains both of the following:
>
>   \alias "Staff"
>   \alias "Voice"
>
> My knowledge of contexts is not extensive, but I suggest that the test
> that \change applies is too simple.

The test is

  else if (it.get_outlet ()->is_alias (to_type))
    {
      // No enclosing context was found because the iterator's immediate
      // context is the kind that was sought.
      /* We could change the current translator's id, but that would make
         errors hard to catch.

         last->translator_id_string () = get_change
         ()->change_to_id_string (); */
      result = _f ("not changing to same context type: %s", ly_symbol2string 
(to_type).c_str ());
    }

and that's indeed crapola.  What the test should do is check whether the
current context type would be accepted into the hierarchy of the
proposed parent.

A more rigid test would be to check whether the current context type
would be accepted by the parent directly.  But I'm not sure we should
rely on such knowledge as a user interface: there might be good reasons
for moving additional (mostly implicit) layers into the context
hierarchy without having to change the bulk of the music.

-- 
David Kastrup



reply via email to

[Prev in Thread] Current Thread [Next in Thread]