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>
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.
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...
`\consists` seems to imply aggregation or possibly even containment.
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. Rather, they co-exist and work along side during the
process. 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? 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`.
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`.
-- Aaron Hill
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user