[Top][All Lists]

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

Re: Naming output files

From: Carl D. Sorensen
Subject: Re: Naming output files
Date: Thu, 26 Feb 2009 08:20:37 -0700

On 2/26/09 3:32 AM, "Reinhold Kainhofer" <address@hidden> wrote:

> Hash: SHA1
> On Donnerstag, 26. Februar 2009 10:58:19 Mats Bengtsson wrote:
>> The obvious follow-up question is, why you get the additional number
>> even when the file name would
>> be unique without the number, i.e. when the output-suffix is set
>> differently for each book block.
>> I realize that it probably requires a few more lines of code in the
>> LilyPond implementation to handle
>> the book-keeping, but it would still be a valuable feature.
> It would actually be quite simple to implement: In scm/lily-library.scm in the
> print- book-with function, instead of storing the file count as a number in
> 'output-count, store it in an alist (which is set as the 'output-count parser
> variable), with the suffix as key. This way, the counting is per suffix and
> we'll automatically not append the number for the first file with a given
> suffix...
> I think this would be quite a nice task or a frog, so I'm not coding it
> myself, just giving a few pointers... The way to work with the alist (that's
> Scheme's idea of a Hash) can be seen e.g. in my counter snippet on LSR:

I agree with Reinhold that this is a good task for a Frog.  Anybody want to
take it over?

BTW, Reinhold, your statement " alist (that's Scheme's idea of a Hash) is
not strictly correct.  Scheme does have Hashes as well, and for data that's
large and relatively static the hash code is more efficient.  So, for
example, predefinedFretboards is a hash, instead of an alist.  But for most
uses in LilyPond, data with keys is stored in alists rather than hashes.

> All you need to do is to use assoc-ref instead of count and ly:parser-define!
> (instead of the set! in the counter example) with assoc-set! to set one entry
> of the hash / alist. The key for the alist would be the suffix. The rest of
> the function doesn't even need to be changed...
> Cheers,
> Reinhold
> PS: Why do we call (string-regexp-substitute "[^a-zA-Z0-9-]" "_" output-
> suffix) on the suffix? This makes it impossible to use e.g. "Flöte" as the
> suffix, which is German for Flute! Similar, any other accented or non-latin
> letter is not possible and will be replaced by a "_". Similarly, spaces or +
> etc. are also not allowed... I understand that some letters may cause problems
> (in particular, ":", "/", "\" and maybe also "?" and "*"), but I don't think
> this is a reason to prevent everything other than latin letters and numbers.

Do all filesytems allow accented characters?  IIRC, some FAT filesystems
don't allow them.


reply via email to

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