Paul Morris wrote > Or, probably better, introduce some kind of "passes as" property where you > could tell other contexts to "treat this context like X context for > purposes of accepting/rejecting it".
On second thought, why not just use the existing \alias for this too? Most of the time if we want commands from context-X to work in context-Y (by using \alias context-X), we also want context-Y to be accepted wherever context-X is accepted. So when say context-Z is determining whether to accept a new context-Y... have it first check context-Y's name, and if the name is unknown (not in its "accepts" list) then have it check context-Y's alias (context-X). If the alias context-X is in the "accepts" list, then context-Z would accept context-Y. In rare cases where we didn't want these things coupled (where we wanted commands from context-X to work in context-Y, but we didn't want context-Y to be accepted wherever context-X is accepted), then we could use \denies and \accepts to define exactly where we want context-Y to be accepted or denied. This would really simplify the process of creating custom contexts, especially in the common case of wanting a modified version of an existing context that works everywhere it does. Basically, it would work the way Jim expected it to. Anyway, it certainly seems like it would be a simplification and improvement, looking at it from this angle, but I'm not really familiar with how these things are used internally by LilyPond, so there may be more to it, reasons why it is set up the way it is... -Paul -- View this message in context: http://lilypond.1069038.n5.nabble.com/Defining-new-contexts-tp172185p172264.html Sent from the User mailing list archive at Nabble.com. _______________________________________________ lilypond-user mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-user
