ly:context-property-where-defined returns differently depending on if a property is unset or explicitly set to '() – I'm guessing this is one of the things you had in mind by "not really pretty"?
On Sat, Jan 4, 2025 at 5:18 PM David Kastrup <d...@gnu.org> wrote: > Dan Eble <dan@lyric.works> writes: > > > Old-timers, > > > > For some reason, I had it in my head that a context property could not > > be set to *unspecified*, but now that I have looked again, I see that > > that is false. It is possible to set a property to *unspecified* and > > mask the value from the enclosing context, just like setting any other > > value. > > > > The new \contextPropertyCheck [1] function is affected by my mistake, > > and I would like to correct it. > > > > Before I extend \contextPropertyCheck to handle the possibility that a > > property is set to *unspecified*, I want to make sure that in general, > > the current treatment of *unspecified* is the desired treatment. > > > > I thought to use ChatGPT (that charlatan) to look for leads on > > real-world uses of *unspecified*. It would have me believe that these > > are effectively the same and are documented as such: > > > > \set property = #*unspecified* > > \unset property > > > > They are not the same, and I don't see this in the current > > documentation, but was there ever a time when they were the same? > > No. There is some overlap of unset properties and properties set to '() > which is not really pretty but possibly a hangover from the LISP mindset > where (not 1) and '() are the same, namely NIL. > > But I don't think *unspecified* was ever really used in LilyPond. > > -- > David Kastrup > >
