bug-lilypond
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lilypond-book: filename option


From: John Williams
Subject: Re: lilypond-book: filename option
Date: Mon, 4 Apr 2005 23:02:13 -0600 (MDT)

On Tue, 5 Apr 2005, Han-Wen Nienhuys wrote:
> address@hidden writes:
> > On Mon, 4 Apr 2005, Han-Wen Nienhuys wrote:
> > > address@hidden writes:
> > > > This resurrects the filename option and makes it do something useful.
> > > >
> > > > If <lilypond filename="bach"> is given, "bach" will be used as the
> > > > basename for the files (instead of "lily-12345678").
> > > >
> > > > This allows the files to have friendlier names, and for the snippets
> > > > to be managed better.
> > >
> > > Can you explain this in more detail?
> >
> > Having predictable filenames for the music snippets in a project makes
> > them a whole lot easier to manage, especially if it turns out that you
> > need to do something which the lilypond authors did not think of for you.
>
> Sorry, I've mistaken your patch. I thought you were going to do
>
>         bach-124748.ly
>
> > For example, say lilypond-book chokes on your source file because python's
> > regexp engine could not handle a file that large.  You might pull the
>
> Can you file a bugreport for this?  IIRC, this has been rectified in
> recent Python releases.

I think it has been too.  I just needed an example.  That happened to me
about a year ago, when I was still using redhat-7.3.  (I really appreciate
the stability of open source software.)

I hacked this into lilypond-book version 2.0.1, but I didn't submit the
patch when I saw that lilypond-book had gotten a complete rewrite in the
dev version.

> > Or maybe you would like some of the music images to link to midi files
> > instead of lilypond source files.  (For example, if you are *not* trying
> > to educate your readers on how to use lilypond.)  Creating the midi files
> > and linking to them is a lot easier if you know what the names of the the
> > .ly and .midi files will be.  Especially if you do not want to link to
> > _all_ of them because some are rather trivial, like a single quarter note.
> >
> > Or maybe you would just prefer that your user see "bach-cantata-1.png" in
> > the browser or html source instead of "lily-394747432.png".
>
> I'm missing one thing: how do you make sure that files are recompiled
> when the .ly source inside the .html is changed?

That was already there, more or less.  This bit in ly_is_outdated:

                if ok and (use_hash_p \
                           or self.ly () == open (ly_file).read ()):

was supposed to do that if use_hash_p was false.  I just added a check for
the filename option, and fixed a bug which went unnoticed because
use_hash_p is never false.  (self.full_ly instead of self.ly)

                if ok and (not use_hash_p or FILENAME in self.option_dict):
                        ok = (self.full_ly () == open (ly_file).read ())

> I think it would be better to keep the lily-NUMBER naming scheme, and
> have lilypond-book (sym)link those with the user-supplied file
> names. In this way, we can have both dependency tracking and readable
> links.

Personally I don't like all those files building up and lying around after
the snippets change the name to something else.  Random number are great
for transaction protocols and such, but for things which persist like
files (functions, machines, etc.), I think random numbers are completely
inappropriate.  If I'm going to have to deal with something more than
transiently, I like to give it a name I can remember.

"There's a problem compiling lily-314159.ly...  Which snippet is that?
grep 313159 source.  Oops, grep 314159 source.  Still nothing.
grep 413159 source.html.  I mean grep 314159 source.html.   Need more
context.  vim source.html, search for 314159 ... Oh, that snippet.
quit.  vim source.  find the snippet.  What was the error again?"

~ John Williams






reply via email to

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