On Mon, Feb 16, 2015 at 4:01 PM, Paul Morris wrote:
> > On Feb 16, 2015, at 2:06 PM, David Nalesnik
> wrote:
> >
> > In this case, KeySignature has both key-signature-interface and
> key-cancellation-interface, but KeyCancellation only has
> key-cancellation-interface, so you can still use inter
> On Feb 16, 2015, at 2:06 PM, David Nalesnik wrote:
>
> In this case, KeySignature has both key-signature-interface and
> key-cancellation-interface, but KeyCancellation only has
> key-cancellation-interface, so you can still use interfaces here.
Thanks David N. Yes, I see. Although I thin
> On Feb 16, 2015, at 1:20 PM, David Kastrup wrote:
>
> That only documents functions written in C++. We don't really have a
> reasonably complete compendium of user-accessible LilyPond programming
> resources.
Ok, thanks for the tip. It would be nice to have more complete documentation
of pu
On Mon, Feb 16, 2015 at 1:30 PM, David Kastrup wrote:
> David Nalesnik writes:
>
> > I suppose even better would be to come up with a way to automatically
> > document public Scheme functions, but I wouldn't know how to do that
> > at this point.
>
> Shouldn't actually be too hard. But I doubt
David Nalesnik writes:
> I suppose even better would be to come up with a way to automatically
> document public Scheme functions, but I wouldn't know how to do that
> at this point.
Shouldn't actually be too hard. But I doubt that all functions with doc
strings would actually make sense in the
On Mon, Feb 16, 2015 at 12:20 PM, David Kastrup wrote:
> Paul Morris writes:
>
> > dak wrote
> >> Paul Morris <
> >
> >> paul@
> >
> >> > writes:
> >>> Hmmm... would it be a good idea to also have a ly:grob-has-interface
> >>> scheme
> >>> function?
> >>
> >> How would it differ from the existin
On Mon, Feb 16, 2015 at 10:04 AM, Paul Morris wrote:
P.S. FWIW, here's one marginal use case. I've been using grob names to
> differentiate key signature grobs from key cancellation grobs, within a
> custom engraver that acknowledges the key-signature-interface. I could add
> a second engraver
Paul Morris writes:
> dak wrote
>> Paul Morris <
>
>> paul@
>
>> > writes:
>>> Hmmm... would it be a good idea to also have a ly:grob-has-interface
>>> scheme
>>> function?
>>
>> How would it differ from the existing grob::has-interface
>
> Um... oops, I guess it wouldn't... Never mind, I just
dak wrote
> Paul Morris <
> paul@
> > writes:
>> Hmmm... would it be a good idea to also have a ly:grob-has-interface
>> scheme
>> function?
>
> How would it differ from the existing grob::has-interface
Um... oops, I guess it wouldn't... Never mind, I just didn't know about
grob::has-interfac
Paul Morris writes:
> David Nalesnik-2 wrote
>> On 2015/02/16 07:56:10, dak wrote:
>>> "Needing to determine the name of a grob" should actually rarely be
>>> necessary:
>>> the pervasive information connected to the functionality of a grob is
>>> rather its
>>> interfaces. That's the usual crit
David Nalesnik-2 wrote
> On 2015/02/16 07:56:10, dak wrote:
>> "Needing to determine the name of a grob" should actually rarely be
>> necessary:
>> the pervasive information connected to the functionality of a grob is
>> rather its
>> interfaces. That's the usual criterion for deciding whether to
On 2015/02/16 13:46:29, david.nalesnik wrote:
On 2015/02/16 07:56:10, dak wrote:
> On 2015/02/15 19:54:19, david.nalesnik wrote:
> > Please review. Thanks!
>
> "Needing to determine the name of a grob" should actually rarely be
necessary:
> the pervasive information connected to the functional
On 2015/02/16 07:56:10, dak wrote:
On 2015/02/15 19:54:19, david.nalesnik wrote:
> Please review. Thanks!
"Needing to determine the name of a grob" should actually rarely be
necessary:
the pervasive information connected to the functionality of a grob is
rather its
interfaces. That's the
13 matches
Mail list logo
