On Sat, Jul 18, 2009 at 12:42 PM, Mark Polesky wrote:
>
> Patrick McCarty wrote:
>> I think it would be better to work on other things right now. :-)
>> Unless someone else jumps in and explains exactly how event classes
>> work, that is.
>>
>> I'll put it on my TODO list. The IR really needs to
Patrick McCarty wrote:
> I think it would be better to work on other things right now. :-)
> Unless someone else jumps in and explains exactly how event classes
> work, that is.
>
> I'll put it on my TODO list. The IR really needs to be cleaned up wrt
> StreamEvents and related items.
Right no
expressions",
>> but right now everything is bundled together. All of those other
>> C++-only events (RemoveContext, ChangeParent, etc.) should be
>> documented too. And should they be renamed along with StreamEvent?
>>
>> ***
>>
>> Sorry for the stream of
ll of those other
> C++-only events (RemoveContext, ChangeParent, etc.) should be
> documented too. And should they be renamed along with StreamEvent?
>
> ***
>
> Sorry for the stream of thought. This has been bugging me lately too. :-)
No problem. I'm happy to help, but I don't
On Fri, Jul 17, 2009 at 8:02 PM, Mark Polesky wrote:
>
> I noticed this thread from two years ago:
> http://lists.gnu.org/archive/html/lilypond-devel/2007-07/msg00020.html
>
> Apparently, StreamEvent should be renamed stream-event. I'm happy to do
> that, but is it reall
I noticed this thread from two years ago:
http://lists.gnu.org/archive/html/lilypond-devel/2007-07/msg00020.html
Apparently, StreamEvent should be renamed stream-event. I'm happy to do
that, but is it really as simple as changing these 2 lines (lines 12-13)
in scm/define-event-classes.scm?
StreamEvent is listed in define-event-classes.scm, but the
capitalization of itself and its "children" makes it look more
like it belongs in define-event-classes.scm with the other
FooEvents...
- Mark
___
lilypond-devel ma
On Monday 02 July 2007, Werner LEMBERG wrote:
> > The historical reason is that in the beginning, all event classes
> > were named in CamelCase, but when all music event 'types were added
> > as classes, I kept the lisp-style naming. I agree that it's the
> >
> The historical reason is that in the beginning, all event classes
> were named in CamelCase, but when all music event 'types were added
> as classes, I kept the lisp-style naming. I agree that it's the
> naming of StreamEvent that should change.
Will you
On Wednesday 27 June 2007, Werner LEMBERG wrote:
> There's a single event class, StreamEvent, which uses uppercase
> letters in its name. Wouldn't be stream-event a better name, similar
> to all others?
The historical reason is that in the beginning, all event classes were
> > To be more precise, we have for example `AbsoluteDynamicEvent' for
> > music expressions and `absolute_dynamic_event' as a music class,
> > but `StreamEvent' is the name of both a music expression and a
> > music class; the latter should be `stre
Werner LEMBERG escreveu:
>> There's a single event class, StreamEvent, which uses uppercase
>> letters in its name. Wouldn't be stream-event a better name, similar
>> to all others?
>
> To be more precise, we have for example `AbsoluteDynamic
> There's a single event class, StreamEvent, which uses uppercase
> letters in its name. Wouldn't be stream-event a better name, similar
> to all others?
To be more precise, we have for example `AbsoluteDynamicEvent' for
music expressions and `absolute_dynamic_even
There's a single event class, StreamEvent, which uses uppercase
letters in its name. Wouldn't be stream-event a better name, similar
to all others?
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.o
14 matches
Mail list logo
