[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: problematic commit 02fe038744e634b42f1a3377c4f0dc3d25e80344
From: |
Valentin Villenave |
Subject: |
Re: problematic commit 02fe038744e634b42f1a3377c4f0dc3d25e80344 |
Date: |
Sun, 24 Oct 2010 18:17:31 +0200 |
On Sun, Oct 24, 2010 at 2:35 PM, Neil Puttock <address@hidden> wrote:
> Well, to be fair, it's not the music function that's the problem;
> rather, you've neglected to make `make-void-music' a thunk, which
> means it's evaluated immediately music-functions.scm is loaded.
I had initially defined it using parentheses, because it's the only
way to add a doc-string. But I thought it would be cleaner to remove
the parentheses. Uh, ironic.
> Believe me, I understand your frustration
I don't think you do. (But that's another problem, I'm trying to keep
it cool here.)
> but a change like this needs a more considered approach which I
> don't think we can afford at the moment.
Sure. But you certainly do understand that my most pressing concern is
the user-exposed syntax.
For the past two years my main occupation has been to go and visit
music schools, conservatories, teaching facilities, small non-profit
associations here and there in France, trying to promote LilyPond and
convince people that they can *actually* use it. My whole sales-pitch
is based on "Every musician can easily type note names: `do, re mi, fa
sol etc.' Do not think of LilyPond as a programming language, think of
it as the way musicians naturally express themselves!".
Then comes the hardest part: "Okay, now open your text editor, and
type, er, `\include "italiano.ly"'."
I can't tell you the look on their faces at this point.
That being said, I understand that this may not be much of an issue
for English-speaking users (and developers).
> You can keep the `make-void-music' if you fix the bug (it just needs
> parentheses around the name).
I absolutely have no interest in keeping this function. In case you
haven't noticed, that wasn't the point.
Whilst I agree with you that my solution isn't (well, wasn't) elegant,
it does have one advantage over yours: what you're suggesting is that
*all* pitchname alists should be defined and loaded at launch time, no
matter which one will actually be used. Granted, that's not much of an
overhead, but still.
In all fairness, I cannot say I'm entirely happy with removing it
altogether. (Euphemism inside.)
Well, thanks for the support.
Cheers,
Valentin.