Werner LEMBERG <w...@gnu.org> writes: >> What we're discussing is ideas. No-one has to implement ideas. > > Well... > >> If there is widespread agreement that the idea is good, then at some >> point it could be implemented. > > ... but as David has correctly mentioned previously, it is not > fruitful to discuss something for a long time and make everyone agree > to it, just to find out later on that the idea can't be implemented in > the current framework.
"Case insensitity" is something that comes up a lot in computing, like with file systems. The general trend is that more and more systems that have started out case insensitive are moving to case sensitivity since the problems caused by inconsistent usage can't be all salvaged automatically. Most programmers with significant exposure to making case insensitivity work develop a deep dislike against the barrage of recurring problems. So before choosing case insensitivity as a solution to some problem, it might make sense to revisit the problem and see whether, for example, killing CamelCaps and/or other naming choices and/or replacing them by different schemes will not make the problem less relevant as it now appears to users. > It's a matter of fact that we are bound to what we have. Everything > else would be a complete redesign of LilyPond, which is certainly a > noble goal but far, far away. I don't think this is the intention of > GLISS. Guile itself would not mind case-insensitivity much, but our existing code base would. Not on a technical level, but with regard to the current naming choices and possible conflicts. >> We could certainly use it as a way to direct development - "hey, >> David, when you're working on the parser, could you also work towards >> making it case insensitive?". Reserved words are lowercase anyway. For the rest, try (read-enable 'case-insensitive) at the top of scm/lily.scm. Good luck. I really have no idea how far this will get you. But I don't want this in LilyPond myself: as I said, allowing inconsistent entry does not buy you anything but sloppiness and surprises. > The case sensitivity is special since it doesn't need syntactical > changes. However, other issues we've discussed recently are very > difficult to implement for reasons that most of us don't understand. Well, some of the things that _are_ implemented are very difficult to implement as well (I am working on dialing back the complexity, too). But if things create _conceptual_ complexity rather than implementation complexity (due to parser limitations), I like them even less. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel