David Kastrup <d...@gnu.org> writes: > Within your own scores, be consistent in your choices. How this > consistency looks, does not matter. Within LilyPond, there is a large > consistency which elements are uppercase, and which lowercase. The one > thing that actually gets annoying is CamelCase. However, as a rule, > camelcase starts with lowercase letters. With recent changes in the > lexer, it would be possible to replace the CamelCase words with dashed > words. That would allow for things like > > \slur-up \slur-down \voice-one \one-voice \voice-two and so on. I am > personally not a big fan of CamelCase. You would, of course, get the > same principal problem "I can't remember where and whether to put > dashes" when making use of that option. > > Weeding out CamelCase would not, in itself, change the classes of things > that we use uppercase for, lowercase for, and dashes for (there would be > some overlap in classes since we _do_ have a few existing > words-with-dashes and \commands-with-dashes, but distinguishing those > classes is actually not important, unlike the pure lower/uppercase > distinction we actually use for Grob and Context names).
Just quoting this as yet another example where I offer some concrete suggestions in a GLISS thread with nobody bothering to even reply. > I don't think that this characterization is doing justice to the > developers since it basically assumes that their main incentive is > making fun of users. > > Part of the reason working on LilyPond is less rewarding than it could > be is this atmosphere of distrust, and the urge to rein in developers > who apparently have nothing better to do than damage LilyPond. "distrust" is maybe too strong a word. "non-involvement" may be closer to the truth. Regarding the GLISS discussions and proposals in that context becoming official project policy, participation of programmers is actively discouraged. Goals are being set without bothering to look at how the existing and developing code base and its underlying design will support them. For me, one of the pillars of userfriendliness is coherence of design. When a user is able to predict how to do something. If programmers are not supposed to participate in the design process, and non-programmers will not be participating in executing this design, we get to the situation where those who have the means of implementing a design will do this ad-hoc, stealthily, and without communication or coordination. "Stealthily" may seem like too strong a word, but quite a few of the actual usability/language features are proposed and finally implemented in the way we see in <URL:http://code.google.com/p/lilypond/issues/detail?id=2717>. There is minimal feedback by few persons (this particular issue has already gotten more feedback than usual in its first iterations and will presumably pass into LilyPond silently once nobody can think of something to particularly dislike). If you take a look at our "Changes" file from 2.16 and take a look at how many of those changes were the result from following through with active and planned policy decisions rather than spontaneously done work, it does not appear that our purported planning is connected much to what actually gets done, and users could exercise more influence if they actually commented on issues in the tracker accompanying actual work in progress rather than participating in a hypothetical discussion detached from the realities of both our code base and worker base. One issue/review that recently profited a lot from interaction of developers and users was <URL:http://code.google.com/p/lilypond/issues/detail?id=2823> where people cooperated in collecting and completing information, leading to a much better informed approach to actual work. If you take a look at _who_ collected the various bits of information, however, you'll see the usual suspects again: seasoned programmers, just that some of them acted in the capacity of users in the context of this issue. We definitely can make use of a _lot_ more of this kind of user involvement and exchange of knowledge, interest, and inspiration, but I don't see that the syntax discussions and decisions detached from the actual development are facilitating this. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel