Flaming Hakama by Elaine <[email protected]> writes: > On Fri, Jun 15, 2018, 1:42 AM David Kastrup <[email protected]> wrote: > >> David Kastrup <[email protected]> writes: >> >> > Flaming Hakama by Elaine <[email protected]> writes: >> > >> >> I think that conveys more clearly what is happening. >> > >> > Not really: that remains something to look up in the documentation. >> > >> > Now I'll readily admit that \consists / \remove does not make for an >> > appealing antonym pair. I'd be leary after all this time of turning a >> > common word like "add" into a reserved word even though "remove" is not >> > better in that regard. But at least it has the advantage of being >> > established. >> >> Some of my argument may be based on some tendency of arguing anything >> out of contrariness. However, this latter point has been irking me >> quite a bit as opposed to the quirky grammar you complain over. > > > It's not really a matter of quirky grammar. > > It's that the term does not convey the relationship in question.
I doubt that we'll manage substantially better. >> While it would likely do nothing to address your complaint, actually >> moving to \consists / \unconsists would, while doubling down on the >> unnaturality you complain about, make for a better pairing, create a >> new keyword very unlikely to be in previous use and free \remove. >> > > So here's a question. > > Is \consist only used to express the relationship between contexts and > engravers? \consists, and basically yes (it's not just engravers but any translator of which engravers are just one subset). > Because if it's just used to with respect to engravers, you could > consider \addEngraver and \removeEngraver. We have translators named *_translator and translators named *_engraver and translators named *_performer . If you want to be precise, this kind of line does not actually add or remove an engraver anywhere but actually causes any context instantiated from the containing context definition to contain or not contain the respective engraver. It adds and removes the instruction to instantiate an engraver as part of instantiating a context from the current context definition. >> Sorry, this is not going at all in the direction you were aiming for >> but from a purely technical standpoint getting rid of \remove would >> be a much more worthwhile target than junking \consists , and >> \unconsists or something of similar awkwardness would be a lot less >> problematic as a newcomer than something as generic as \add . >> > > Quite the contrary. This is helping to elucidate what's actually going > on, and I suspect a more descriptive terminology may result. The less descriptive terminology has the advantage that it does not come as preloaded with precise but incorrect preconceptions. So the tradeoff is a really fuzzy one. > Based on Urs' comment, if it is more like registering a callback, how > about \register and \unregister? The "callback" is what is called a "listener". A translator is a whole collection of listeners as well as internal state and logic. That doesn't mean "register" is incorrect but we also register possible child context types. So it's again more a case of a really fuzzy tradeoff. -- David Kastrup _______________________________________________ lilypond-user mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-user
