Aaron Hill <lilyp...@hillvisions.com> writes: > On 2018-06-15 03:29, David Kastrup wrote: >> Flaming Hakama by Elaine <ela...@flaminghakama.com> writes: >>> On Fri, Jun 15, 2018, 1:42 AM David Kastrup <d...@gnu.org> wrote: >>>> 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. > > <sarcasm>Why not call it `\xyzzy` then?</sarcasm>
Because it comes with no preconceptions, precise or fuzzy. > I would debate that preconceptions are the lesser evil when stacked up > against the potential of undescriptive and/or misleading terms. If > the terminology is not clear enough, then it is significantly harder > to correct or override a preconception. Of course, we should avoid > cluttering the user experience with all of the gory details of the > underlying mechanisms; but if folks are uncomfortable with the casual > reading of `\consists`, then it would seem that it is a poor word > choice indeed. I have seen a grammar complaint. > It truly is a shame that `\with` is already used, as the pair of > `\with` and `\without` could be a great way to succinctly state the > relationship in this scenario. Perhaps `\including` and `\excluding` > could work, but then... Too close to \include in my book which is something else entirely. > `\consists` seems to imply aggregation or possibly even containment. So? > This sounds like one of the incorrect preconceptions we are wanting to > avoid, since it is my understanding that the associated engravers, et > al. are *not* to be considered an element of the context that > `\consists` them. Not? > Rather, they co-exist and work along side during the process. Engraver/translator instances are particular to a certain context. The context exercises its contained translator_group implementation as the main manner of its operation. If that sounds opaque it is because the terminology at the C++ level is one incoherent mess. I don't see anybody stepping up to clean that up, however. At the LilyPond level, it is comparatively clean in comparison. I'd like to use something like \unconsists instead of \remove (why is this not in the third person singular like the rest anyway?) for comparatively relevant technical reasons. > So, `\including` might even be overstating the relationship here. > (Mind you, the confusion between `\including` and `\include` would be > more than enough to disqualify it anyway.) > > Could `\recognizes` and `\ignores` work? It's much much much more incorrect than what you are coming from. > These words, again, do not imply any form of ownership, rather are > hinting more at some form of permission, granting a translator to do > its work within that context. I would have suggested `\allows` and > `\denies` as simpler words, but the latter already exists along with > its pair `\accepts`. Oh, but now a crazy thought... Could overloading > those existing terms work? That is, would LilyPond be able to tell > the difference between `\accepts "SomeContext"` vs. `\accepts > "SomeEngraver"`? If so, then we could potentially throw away both > `\consists` and `\remove`. Accepting a subcontext into a hierarchy and instantiating a translator are so utterly different things that your request to conflate them in order to make things "more correct" is a complete absurdity. So what then would \defaultchild "some_translator" mean if those are comparable things? > Finally, what about `\with` becoming `\where`? It reads just as > plainly, and would free up the term if we wanted to opt for `\with` > and `\without` as opposed to `\consists` and `\remove`. Frankly, by now I suspect that you did not actually close the sarcasm tag you opened at the start of your comment. -- David Kastrup _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
