[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [GLISS] basics
From: |
Janek Warchoł |
Subject: |
Re: [GLISS] basics |
Date: |
Wed, 26 Sep 2012 12:21:12 +0200 |
On Wed, Sep 26, 2012 at 11:53 AM, David Kastrup <address@hidden> 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...
- Re: [GLISS] basics, (continued)
Re: [GLISS] basics, Joseph Rushton Wakeling, 2012/09/25
Re: [GLISS] basics, Joseph Rushton Wakeling, 2012/09/26
Re: [GLISS] basics, Janek Warchoł, 2012/09/27
Re: [GLISS] basics, Joseph Rushton Wakeling, 2012/09/27