"Phil Holmes" <m...@philholmes.net> writes: > ----- Original Message ----- > From: "David Kastrup" <d...@gnu.org> > To: <lilypond-devel@gnu.org> > Sent: Saturday, September 15, 2012 9:20 AM > Subject: Re: [GLISS] - alternative viewpoint > > >> "Phil Holmes" <em...@philholmes.net> writes: >> >>> And getting rid of case-sensitivity in a lot of this? >> >> You need to elaborate. It is not clear what you mean with that, and >> what kind of remedy you envision. > > > \new Staff works. \New staff doesn't. There's no reason for that -
There is actually a reason for that. Staff, as a context name, is a container for properties, and things like Slur, as a property name, are also principally containers for properties. There is a convention to uppercase them in order to distinguish them from other elements. When writing things like \layout { \context { \Staff \override ... } } calling the identifier \Staff for copying an existing context definition is not syntactically different from calling any other kind of identifier including functions. We use the uppercasing here in order to establish some kind of namespace. The one consequence that I find actually annoying about that is that we have the semi-equivalence of \score with \new Score, and that is indeed less than pretty. > we don't have two separate \new \New commands that do different > things, nor two contexts Staff and staff that are different. But \Score and \score which are entirely different things (the latter is actually a reserved word, so they can't really be merged). > Worse is that \slurUp works but only with that precise casing. Given that it works on a grob called Slur, I agree that some of the consequences of our naming schemes are not necessarily fortunate. \upSlur would fit better into the schemes, but I don't fancy its grammar. In practice, \voiceOne and \voiceTwo are more often than not the saner choice (as they make for more consistent results usually since the user often forgets to include the more obscure *Up/*Down commands), or using ^ and _ on individual slurs (since it is rare that you actually want to direct only slurs but nothing else for longer passages). > TBH this specific one doesn't cause me worry, since I remember it, but > there are much more arcane casings that I have to refer to the manual > to find - so I can remember the command, but not the casing! From a > user perspective, it would be much simpler if everything they write > was ToLower()-ed before further processing. With the current design, it is not as simple as that right now. Of course, there is the standard argument (known from filesystem discussions) that lowercasing is not a well-defined operation since some people expect \lowercase{I} to be {i} and some expect it to be {ı} and \uppercase{i} to be either {I} or {İ}. As long as we allow arbitrary utf8 characters into identifiers, that is not an entirely hypothetic consideration. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel