Re: lilypond ./ChangeLog Documentation/user/music-g...

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: lilypond ./ChangeLog Documentation/user/music-g...

Han-Wen Nienhuys
Graham Percival wrote:
> Log message:
> Direction #-1 to #down.

actually, in most cases, \down and \up should also work. That might be
more lilyesque.

--
  Han-Wen Nienhuys - [hidden email] - http://www.xs4all.nl/~hanwen


_______________________________________________
lilypond-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: lilypond ./ChangeLog Documentation/user/music-g...

Graham Percival-2

On 18-Aug-05, at 5:21 PM, Han-Wen Nienhuys wrote:

> Graham Percival wrote:
>> Log message:
>> Direction #-1 to #down.
>
> actually, in most cases, \down and \up should also work.

Hmm, I didn't know that.

>  That might be more lilyesque.

I disagree -- we use #3 and #'(1 . -2) for many things (padding,
extra-offset), so
I think it's a good idea to continue using #up and #down.  This
reinforces the general
form of
\override (engraver.)grob #'property = #value

Cheers,
- Graham



_______________________________________________
lilypond-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: lilypond ./ChangeLog Documentation/user/music-g...

Han-Wen Nienhuys
Graham Percival wrote:

>
> On 18-Aug-05, at 5:21 PM, Han-Wen Nienhuys wrote:
>
>> Graham Percival wrote:
>>
>>> Log message:
>>>     Direction #-1 to #down.
>>
>>
>> actually, in most cases, \down and \up should also work.
>
>
> Hmm, I didn't know that.
>
>>  That might be more lilyesque.
>
>
> I disagree -- we use #3 and #'(1 . -2) for many things (padding,
> extra-offset), so
> I think it's a good idea to continue using #up and #down.  This
> reinforces the general
> form of
> \override (engraver.)grob #'property = #value

Hmm. There's still a question of style, in lily-library.scm we do

(define-public X 0)
(define-public Y 1)
(define-safe-public START -1)
(define-safe-public STOP 1)
(define-public LEFT -1)
(define-public RIGHT 1)
(define-public UP 1)
(define-public DOWN -1)
(define-public CENTER 0)

perhaps we should do #UP and #DOWN iso. #up and #down ?



--
  Han-Wen Nienhuys - [hidden email] - http://www.xs4all.nl/~hanwen


_______________________________________________
lilypond-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: lilypond ./ChangeLog Documentation/user/music-g...

Graham Percival-2

On 19-Aug-05, at 2:49 AM, Han-Wen Nienhuys wrote:

> Graham Percival wrote:
>> I think it's a good idea to continue using #up and #down.  This
>> reinforces the general
>> form of
>> \override (engraver.)grob #'property = #value
>
> Hmm. There's still a question of style, in lily-library.scm we do
>
> (define-public UP 1)
> (define-public DOWN -1)
> (define-public CENTER 0)
>
> perhaps we should do #UP and #DOWN iso. #up and #down ?

1)  is #up likely to stop working in the future?  It works now, so
evidently there's
a lowercase to uppercase translation happening somewhere.
2)  would it be faster to process #UP instead of #up (ie avoiding that
translation) ?

If it would be slightly faster, then I'd say that we should change the
definitions
in ly/* , but we should leave the input/* snippets (ie the user-viewed
stuff)
alone.  #up is easier to type than #UP.  :)

Cheers,
- Graham



_______________________________________________
lilypond-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: lilypond ./ChangeLog Documentation/user/music-g...

Han-Wen Nienhuys
Graham Percival wrote:
> 1)  is #up likely to stop working in the future?  It works now, so
> evidently there's
> a lowercase to uppercase translation happening somewhere.
> 2)  would it be faster to process #UP instead of #up (ie avoiding that
> translation) ?


> If it would be slightly faster, then I'd say that we should change the
> definitions
> in ly/* , but we should leave the input/* snippets (ie the user-viewed
> stuff)
> alone.  #up is easier to type than #UP.  :)

actually, the point is that "up" is in style for \up, while UP is in
style for #UP. We try to use upcase for global constants in Scheme.

--
  Han-Wen Nienhuys - [hidden email] - http://www.xs4all.nl/~hanwen


_______________________________________________
lilypond-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: lilypond ./ChangeLog Documentation/user/music-g...

Graham Percival-2

On 22-Aug-05, at 2:17 AM, Han-Wen Nienhuys wrote:

> Graham Percival wrote:
>> If it would be slightly faster, then I'd say that we should change
>> the definitions
>> in ly/* , but we should leave the input/* snippets (ie the
>> user-viewed stuff)
>> alone.  #up is easier to type than #UP.  :)
>
> actually, the point is that "up" is in style for \up, while UP is in
> style for #UP. We try to use upcase for global constants in Scheme.

OK, then.  I'll change everything.

- Graham



_______________________________________________
lilypond-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-devel