Re: [GLISS] - alternative viewpoint

[David Kastrup]

Marc Hohl <address@hidden> writes:

> Am 20.09.2012 11:56, schrieb David Kastrup:
>> David Kastrup <address@hidden> 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.
> It is not that I am not interested in this kind of
> discussions/proposals, it is just that I have no problem
> with camelCase/uppercase/lowercase stuff, so I don't need
> a change here; on the other hand, if this would make it
> easier for everyone, then I would not object to a
> "lilypond is all lowercase" change.

The problem is not people not interested in this kind of
discussions/proposals.  The problem is people who stop being interested
in an oh so important problem the moment one tries offering different,
more feasible solutions than what they were thinking of.

If the problem is not important enough to give feasible approaches at a
solution serious consideration (which most certainly would include
explaining in which way they appear inferior to the less feasible
approaches), then it is hard to consider it important enough to bother
with the infeasible approaches.

> I can only speak for myself, but the main "problem" is that most of
> the time I can spend for working on LilyPond is put into the actual
> patches; the reviewing process is handled rather shabbily, I confess.

With regard to reviewing user interface additions, it may indeed be the
case that other developers don't care much since they could get along
fine previously, trust they'll get along fine in future, and maybe trust
other developers not to do all too much damage.

But we don't have users involved either.  And those are actually the
ones for which such additions are made.  Involving them instead in a
planning stage largely disconnected from actual developments is a poor
substitute.

> I take a look at nearly *every* issue when I got an email
> notification, but I often do not find the time to get deeper into the
> problem to understand what the current proposal means or what the
> patch to be review actually does. And just a quick "LGTM, but not
> tested" doesn't help anybody.

That's more or less topical for code changes, like the stuff Mike does.
For documentation and user interface changes (probably with the
exception of things like "try removing the closed music category" which
focuses on obliterating behavior that was not really suitable for
documenting), the target audience are users (a superset of developers,
hopefully).  But we don't have them involved in the feedback.

And I don't think we should wait with getting them involved until my
devious plan of turning users into programmers almost without noticing
bears fruit.

> Do you propose that the user base should get more information
> about development work?

Yes.

> When working on tablature features, I got an *overwhelming*
> response of other users, a lot of "how about x/can you do y"
> stuff which more often than not found its way into tablature.scm.
>
> In other areas, the response was about nil.
>
> So there is no common rule how to get people involved.

Sure.  But with our issue tracker, users don't get involved as a rule.
Even on issues started from a user report.

>> 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.
>
> Well, I am still not sure about the latter.

Within specific sub-areas like tablature support, this apparently works
better than when LilyPond as a whole is concerned.

"Let's write a subsystem/package for this" is just much more manageable
than "let's change LilyPond as a whole".

Obviously, we should strive to change LilyPond as a whole in order to
make it easier to delegate problems to the subsystem/package level.
That allows for much more parallelized processing.

-- 
David Kastrup