lilypond-devel
[Top][All Lists]
Advanced

[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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]