softcoding accepts_list_

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

softcoding accepts_list_

Erik Sandberg-2
hi,

I'm attempting to softcode \accepts and friends. Should the order of \accepts
calls be significant in absence of appropriate \defaultchild? I.e., if we have

\layout {
\context {\Score  \accepts "Foo" \accepts "Bar" }
\context {\name Foo \accepts "Baz" }
\context {\name Bar \accepts "Baz" }
}

\new Score \new Baz { c d e }

.. then the path to Baz is ambiguous. Should we ideally throw a warning and
randomly pick either foo or bar, or should the order be defined by the order
of the \accepts calls?

I would like the first approach better, because ambiguous context paths are
rare and should be clarified; the \defaultchild mechanism should be
sufficient for normal uses.

--
Erik


_______________________________________________
lilypond-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: softcoding accepts_list_

Han-Wen Nienhuys-2
Erik Sandberg escreveu:

> hi,
>
> I'm attempting to softcode \accepts and friends. Should the order of \accepts
> calls be significant in absence of appropriate \defaultchild? I.e., if we have
>
> \layout {
> \context {\Score  \accepts "Foo" \accepts "Bar" }
> \context {\name Foo \accepts "Baz" }
> \context {\name Bar \accepts "Baz" }
> }
>
> \new Score \new Baz { c d e }
>
> .. then the path to Baz is ambiguous. Should we ideally throw a warning and
> randomly pick either foo or bar, or should the order be defined by the order
> of the \accepts calls?

I think it's best to use both: \defaultchild   should always have
preference, but in absence, the order is signifcant.


--

Han-Wen Nienhuys - [hidden email] - http://www.xs4all.nl/~hanwen

LilyPond Software Design
  -- Code for Music Notation
http://www.lilypond-design.com



_______________________________________________
lilypond-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-devel