Werner LEMBERG <w...@gnu.org> writes: >>> there is still the big convert-to-single-path-override patch >>> pending, how available in dev/syntax and discussed in >>> <URL:http://code.google.com/p/lilypond/issues/detail?id=2934>. > > Everything looks fine! Thanks for your efforts. Am I right that > > \override foo.bar > > is the same as > > \override foo . bar > > ? This would be quite important for formatting input files.
Yes, that's the same. In order to make old uses of \overrideProperty "Context.Name" ... blend in, I also made that equivalent. It turns out that there are enough uses of \overrideProperty #"Context.Name" (where an explicit Scheme string is requested and a conversion would seem inappropriate) are around that this incentive was nonsensical. However, this change also makes \override Context.Name work in lyrics mode where it has previously been necessary to write \override Context . Name so I decided to keep it: the special lyricsmode behavior is a pain to explain. How it works now out of the box would be even more painful to explain, but it is unlikely anybody would ask. One can leave the explanation in a place where a curious expert will find it, and nobody will miss it. There would also be some incentive to distinguish quoted and non-quoted strings here, particularly again in lyrics mode, and only allow paths made from unquoted strings. The question then is whether $"xxx" which means "interpret the Scheme string xxx as if it was a LilyPond identifier" or \zzz after zzz=xxx should be allowed to be converted into identifiers. Since zzz=xxx and zzz="xxx" are indistinguishable from the results, it seems like making a distinction here when it is not apparent in the data structure itself after assignment is likely going to cause more pain than gain. Again, this makes one wish a bit for the data model of Lua which does not distinguish strings and symbols, instead interning every string (which essentially is what a symbol is all about). So yes, there is some leeway in the details that are basically judgment calls. I tend to think that most judgment calls were made with a good balance between pain and gain, but if we apply the usual standards of LilyPond development, this would call for at least two months of bikeshedding and exasperation. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
