Urs Liska writes:
> I have written a function to return the lowercase version of a symbol
> for use in my library as
>
> % Return the lowercase version of a symbol
> #(define (symbol->lowercase sym)
>(string->symbol
> (string-downcase
> (symbol->string sym
>
> Just a small questi
Thomas Morley writes:
> Hi,
>
> http://lsr.di.unimi.it/LSR/Snippet?id=1044
> "Workaround for using numbers as part of Lilypond variable names"
> is a new snippet from a member of the german forum.
>
> I'd like to reject it for several reasons:
>
> 1. There's the possibility to use `identifier.1'
Hi,
I am almost done moving multiple/cross-voice spanner code out of specific
engravers into the Spanner_engraver class. I just want to make sure this
approach is on the right track before finishing up and submitting the patch:
New instances of the engraver are created to handle
spanners/events/a
On 2016/08/12 22:04:52, dak wrote:
I repeat:
Can we get to some version of the code where the code paths supposed
to be
equivalent (is there agreement about that?) actually looks the same?
I think the simplest options here are to (1) make the same changes in
both code paths for consistency
On 13.08.2016 10:29, David Kastrup wrote:
\part.1 in contrast is slightly different. I'll work on improvements by
and by but at the current point of time this is not really at a "proudly
announceable by snippets" state. It still has drawbacks and irks.
It seems that others as well as I have b
Am 13.08.2016 um 08:10 schrieb David Kastrup:
> Urs Liska writes:
>
>> I have written a function to return the lowercase version of a symbol
>> for use in my library as
>>
>> % Return the lowercase version of a symbol
>> #(define (symbol->lowercase sym)
>>(string->symbol
>> (string-downc
Nathan Chou writes:
> Hi,
>
> I am almost done moving multiple/cross-voice spanner code out of specific
> engravers into the Spanner_engraver class. I just want to make sure this
> approach is on the right track before finishing up and submitting the patch:
>
> New instances of the engraver are c
Urs Liska writes:
> Am 13.08.2016 um 08:10 schrieb David Kastrup:
>> Urs Liska writes:
>>
>>> I have written a function to return the lowercase version of a symbol
>>> for use in my library as
>>>
>>> % Return the lowercase version of a symbol
>>> #(define (symbol->lowercase sym)
>>>(string-
Simon Albrecht writes:
> On 13.08.2016 10:29, David Kastrup wrote:
>> \part.1 in contrast is slightly different. I'll work on improvements by
>> and by but at the current point of time this is not really at a "proudly
>> announceable by snippets" state. It still has drawbacks and irks.
>
> It s
>Case insensitivity is almost never a good idea. It leads to stuff that
>sometimes works and sometimes fails under mysterious circumstances.
>
>For example, you are aware that in a Turkish locale, I downcases to ı
>instead of i , and i uppercases to İ instead of I ?
>
>And if you do search-and-
Urs Liska writes:
>>Case insensitivity is almost never a good idea. It leads to stuff that
>>sometimes works and sometimes fails under mysterious circumstances.
>>
>>For example, you are aware that in a Turkish locale, I downcases to ı
>>instead of i , and i uppercases to İ instead of I ?
>>
>>A
I've filed
https://sourceforge.net/p/testlilyissues/issues/4955/
Any idea how to circumvent this problem?
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
12 matches
Mail list logo
