Let define-session-public place variables natively into parser (issue 300110043 by d...@gnu.org)

[Carl . D . Sorensen]

Looks very nice to me.  I couldn't have done it, but I love how it
works.

Thanks,

Carl


https://codereview.appspot.com/300110043/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Tie properties vs. slur properties.

[Carl Sorensen]

On 5/25/16 7:26 PM, "lilypond-devel on behalf of tisimst"
 wrote:
>
>P.S. While we're talking properties, is there anyone who'd be willing to
>make the trill spanner squiggle "~" externally \override-able independent
>of the trill text "tr"?

Interestingly enough, the trill spanner squiggle is a Script object, which
is defined in script.scm.  We just had a brief discussion on this very
subject, starting with

https://lists.gnu.org/archive/html/lilypond-devel/2016-05/msg00161.html


If David N's idea of a scriptExceptions property were implemented, that
would provide a means of overriding the trill squiggle.

Alternatively, if we could make scriptDefinitions a user property instead
of an internal property, that would also provide a means of overriding the
trill squiggle.

So I don't think anyone is currently working on it, but it's not an
impossible job to do it.

Thanks,

Carl


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: git-cl problem

[John Gourlay]

I believe my git-cl problem was due to an incorrect setting in my Google 
Account Settings. I was not allowing access by “less secure” apps as described 
in Contributor’s Guide, section 2.3. I wonder if the CG should be revised, 
because it implies that “allowed” is the default, but in my case the default 
appears to have been “not allowed”.

Thanks to all of you who tried to help with this. “git-cl upload" works 
properly for me now.

John Gourlay
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Tie properties vs. slur properties.

[Carl Sorensen]

On 5/25/16 7:26 PM, "lilypond-devel on behalf of tisimst"
 wrote:
>What's the benefit of nesting properties like this? I'm open to hearing
>arguments for it, but why not have them all accessible at top-level? Is it
>programmatically beneficial to have some properties in the "details"
>alist?
>I would argue that it would be more user-friendly if the user didn't need
>to know when to do "Grob.property" vs "Grob.details.property" sometimes.
>I'd vote for making all properties accessible like "Grob.property" if
>that's possible.

At the time I was creating fret diagrams, there was a very large number of
properties that could be varied to change the configuration of the fret
diagrams.  Rather than hardcoding values, I made them all properties.
Han-Wen was reluctant to expand the property name space for properties
that would have only a single use, rather than applying to a variety of
different grobs.

So we arrived at the system of using a details property.  I don't know if
it was newly created along with fret diagrams, or if it had been used for
some other grob previously (most likely it was already in used for slurs
and ties, and we just adapted it).  At any rate, details was used as a
general property that could be customized for a given grob.

The added advantage that David shows for being able to set the details in
one override was not a primary concern at the time I was working on fret
diagrams and harp pedal diagrams.

Thanks,

Carl


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Tie properties vs. slur properties.

[tisimst]

On Thu, May 26, 2016 at 12:50 AM, David Kastrup [via Lilypond] <
ml-node+s1069038n190980...@n5.nabble.com> wrote:

> tisimst <[hidden email]
> > writes:
>
> > On Wed, May 25, 2016 at 12:19 AM, Werner LEMBERG [via Lilypond] <
> > [hidden email] >
> wrote:
> >
> >>
> >> > The tie interface has height-limit and ratio as part of Tie.details.
> >> >
> >> > The slur interface has height-limit and ratio as part of Slur (not
> >> > embedded in Slur.details).
> >> >
> >> > Is there a reason for this difference, or is it just due to never
> >> > making the two be consistent?
> >>
> >> I believe it's the latter.
> >>
> >> > If there is no reason for the difference, I think the two should be
> >> > rationalized, probably by moving Slur.height-limit and Slur.ratio to
> >> > Slur.details.height-limit and Slur.details.ratio.
> >>
> >> This looks ok.
> >>
> >
> > What's the benefit of nesting properties like this?
>
> You don't need to list them individually in an interface.  You can
> override the whole set of details with one command without needing to
> specifically clear properties that are usually never set, but the user
> and/or some containing context may have set them to special values.
>
> If you need to access them as a set anyway, it's faster to get them once
> and go from there.
>
> There may be properties in some "details" that are named identically to
> properties in some other "details" or at top level.
>
> That's what I can currently think of.
>
> I'm not particularly enamored with the details either, but if you take a
> look at stuff like the harp diagram details, they are really a long long
> list.  Overriding all of them individually is effort.
>

Ah, yes. That makes sense. Thank you for making it possible to do both
Grob.details.property and Grob.details = #'((property . ...))

Best,
Abraham




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Tie-properties-vs-slur-properties-tp190944p191003.html
Sent from the Dev mailing list archive at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Tie properties vs. slur properties.

[David Kastrup]

tisimst  writes:

> On Wed, May 25, 2016 at 12:19 AM, Werner LEMBERG [via Lilypond] <
> ml-node+s1069038n19094...@n5.nabble.com> wrote:
>
>>
>> > The tie interface has height-limit and ratio as part of Tie.details.
>> >
>> > The slur interface has height-limit and ratio as part of Slur (not
>> > embedded in Slur.details).
>> >
>> > Is there a reason for this difference, or is it just due to never
>> > making the two be consistent?
>>
>> I believe it's the latter.
>>
>> > If there is no reason for the difference, I think the two should be
>> > rationalized, probably by moving Slur.height-limit and Slur.ratio to
>> > Slur.details.height-limit and Slur.details.ratio.
>>
>> This looks ok.
>>
>
> What's the benefit of nesting properties like this?

You don't need to list them individually in an interface.  You can
override the whole set of details with one command without needing to
specifically clear properties that are usually never set, but the user
and/or some containing context may have set them to special values.

If you need to access them as a set anyway, it's faster to get them once
and go from there.

There may be properties in some "details" that are named identically to
properties in some other "details" or at top level.

That's what I can currently think of.

I'm not particularly enamored with the details either, but if you take a
look at stuff like the harp diagram details, they are really a long long
list.  Overriding all of them individually is effort.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel