On Wed, Sep 26, 2012 at 11:53 AM, David Kastrup <[email protected]> wrote:
> To get back at the hammer analogy, users might ask for a
> heavier hammer if they have problems getting screws in place.  Or for a
> more convenient way to enter/express xxx when they should not be
> required to bother with xxx at all.

Yes, that's a problem.
Anyway, i think that we agree that we'll have to sort user responses
and that not all of them will actually need language changes to solve.

>> Do i understand correctly that you mean "it's good to have helper
>> functions [1] that make code clean and tidy.  It is also good to be
>> able to look at the code of such function and create your own
>> derivative function if necessary"?
>>
>> If so, that's like +111 from me - couldn't agree more.
>>
>> [1] or other helper stuff, even if technically it's not a function
>
> I would not call "an interface to a musical concept" a "helper function"
> just because it is reasonably easy to translate that concept into a
> graphical representation.

I don't understand what you mean here...[1]  Anyway, i should've
provided an example.  By "helper stuff" i mean things like your \at
function, David Nalesnik's \shape, being able to write
\compressFullBarRests instead of \set SkipBars = ##t etc.

best,
Janek

[1] you don't have to explain (unless you care about it a lot) - i
know that we can talk for hours ;) and there's so much other emails
flying around that it's hard to keep up: i haven't done anything other
than email since i've woken up, except for breakfast :P
I'm trying to get my replies shorter...

_______________________________________________
lilypond-devel mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Reply via email to