On 2020-08-29 10:38 am, David Kastrup wrote:
Aaron Hill writes:
Is this pushing things too far?
Well, essentially a similar problem. How do you figure out the
difference between setting something to a context mod, and making a
smart alist modification?
I do not believe there are any contex
Aaron Hill writes:
> On 2020-08-29 6:44 am, David Kastrup wrote:
>> Hm. \with instead of = would even fit into the parser. But that
>> leaves
>> tweaks in the lurch.
>
> Not sure I am following. Are you indicating that something like...
>
>
> \once \override LaissezVibrerTie.details
>
On 2020-08-29 6:44 am, David Kastrup wrote:
Hm. \with instead of = would even fit into the parser. But that
leaves
tweaks in the lurch.
Not sure I am following. Are you indicating that something like...
\once \override LaissezVibrerTie.details
\with { ratio = #0.5 height-limit =
> \propertyTweak finger-code #'below-string
> FretBoard.fret-diagram-details
>
> is completely indistinguishable from
>
> \propertyTweak fret-diagram-details.finger-code #'below-string
> FretBoard
>
> So any commands stacked before this last \propertyTweak command have
> no way of knowing
On 2020-08-29 6:37 am, David Kastrup wrote:
Aaron Hill writes:
On 2020-08-29 5:23 am, David Kastrup wrote:
Wols Lists writes:
On 29/08/20 05:45, Werner LEMBERG wrote:
\once \override FretBoard.size = #'1.0
\once \override FretBoard.fret-diagram-details.barre-type =
#'straight
Aaron Hill writes:
> No need to rewrite anything. We can use \with to assist with this
> pattern:
>
>
> overrideII =
> #(define-music-function
> (prop mods)
> (key-list? ly:context-mod?)
> (define (assign? mod) (eq? 'assign (car mod)))
> (define (proc mod)
> (let ((subprop (cadr
Aaron Hill writes:
> On 2020-08-29 5:23 am, David Kastrup wrote:
>> Wols Lists writes:
>>
>>> On 29/08/20 05:45, Werner LEMBERG wrote:
\once \override FretBoard.size = #'1.0
\once \override FretBoard.fret-diagram-details.barre-type =
#'straight
\once \overr
On 2020-08-29 5:23 am, David Kastrup wrote:
Wols Lists writes:
On 29/08/20 05:45, Werner LEMBERG wrote:
\once \override FretBoard.size = #'1.0
\once \override FretBoard.fret-diagram-details.barre-type =
#'straight
\once \override FretBoard.fret-diagram-details.dot-color =
On 2020-08-28 9:45 pm, Werner LEMBERG wrote:
No. I'm against it. Introducing abbreviations into examples is a
slippery slope and sets a bad precedent. In my scores I use \t for
\tuplet, but I would never inflict that on any public example, even
to save space. Wrapped lines are not a visual or
On 2020-08-29 3:19 am, Wols Lists wrote:
On 29/08/20 05:45, Werner LEMBERG wrote:
\once \override FretBoard.size = #'1.0
\once \override FretBoard.fret-diagram-details.barre-type =
#'straight
\once \override FretBoard.fret-diagram-details.dot-color =
#'black
\once \over
Wols Lists writes:
> On 29/08/20 05:45, Werner LEMBERG wrote:
>> \once \override FretBoard.size = #'1.0
>> \once \override FretBoard.fret-diagram-details.barre-type = #'straight
>> \once \override FretBoard.fret-diagram-details.dot-color = #'black
>> \once \override FretBo
Werner LEMBERG writes:
>>> BTW, would it be possible to enhance `\propertyTweak` to write
>>>
>>> \propertyTweak fret-diagram-details.dot-color #'white
>>> FretBoard
>>>
>>> as
>>>
>>> \propertyTweak dot-color #'white
>>> FretBoard.fret-diagram-details
>> BTW, would it be possible to enhance `\propertyTweak` to write
>>
>> \propertyTweak fret-diagram-details.dot-color #'white
>> FretBoard
>>
>> as
>>
>> \propertyTweak dot-color #'white
>> FretBoard.fret-diagram-details ?
>
> Have you even tried?
Only
On 29/08/20 05:45, Werner LEMBERG wrote:
> \once \override FretBoard.size = #'1.0
> \once \override FretBoard.fret-diagram-details.barre-type = #'straight
> \once \override FretBoard.fret-diagram-details.dot-color = #'black
> \once \override FretBoard.fret-diagram-details.fi
Werner LEMBERG writes:
>> Maybe
>>
>> \void \displayLilyMusic
>> \once
>> \propertyTweak color #red
>> \propertyTweak font-size #3
>> \propertyTweak direction #UP Voice.Slur
>>
>> helps?
>
> It does, thanks a lot! I didn't have this function on my radar, and
> it isn't documented in the NR at
> Maybe
>
> \void \displayLilyMusic
> \once
> \propertyTweak color #red
> \propertyTweak font-size #3
> \propertyTweak direction #UP Voice.Slur
>
> helps?
It does, thanks a lot! I didn't have this function on my radar, and
it isn't documented in the NR at all.
Attached a version using \proper
> No. I'm against it. Introducing abbreviations into examples is a
> slippery slope and sets a bad precedent. In my scores I use \t for
> \tuplet, but I would never inflict that on any public example, even
> to save space. Wrapped lines are not a visual or semantic issue to
> me at least. Ple
On 28/08/2020 20:42, Werner LEMBERG wrote:
Well, we have to make a compromise. The PDF document has a small line
width, and you can't scroll horizontally...
Theoretically, the snippet could be printed with a smaller font size,
but this doesn't look very pretty IMHO. I consider the `\oo`
shor
No. I'm against it. Introducing abbreviations into examples is a
slippery slope and sets a bad precedent. In my scores I use \t for
\tuplet, but I would never inflict that on any public example, even to
save space. Wrapped lines are not a visual or semantic issue to me at
least. Please don't do
Werner LEMBERG writes:
>>> Well, we have to make a compromise. The PDF document has a small
>>> line width, and you can't scroll horizontally...
>>
>> Then you just have to wrap the line.
>
> I'm Mr. Wrap-Line, as can be seen by many of my commits. If I think
> that wrapping is suboptimal and
>> Well, we have to make a compromise. The PDF document has a small
>> line width, and you can't scroll horizontally...
>
> Then you just have to wrap the line.
I'm Mr. Wrap-Line, as can be seen by many of my commits. If I think
that wrapping is suboptimal and reduces legibility I hope you ha
>> Well, we have to make a compromise. The PDF document has a small line
>> width, and you can't scroll horizontally...
>>
>> Theoretically, the snippet could be printed with a smaller font size,
>> but this doesn't look very pretty IMHO. I consider the `\oo`
>> shorthand both innocuous and sim
Werner LEMBERG writes:
>>> However, saying
>>>
>>> \oo VeryLong.Grob.PropertyToBeChanged = foo
>>>
>>> for this (and only this) snippet is just fine.
>>
>> I don't think that it makes sense for snippets to introduce
>> convenience shorthands unless the snippet in itself tries is about
>> showc
On Fri, Aug 28, 2020 at 8:52 AM Werner LEMBERG wrote:
> >> However, saying
> >>
> >> \oo VeryLong.Grob.PropertyToBeChanged = foo
> >>
> >> for this (and only this) snippet is just fine.
> >
> > I don't think that it makes sense for snippets to introduce
> > convenience shorthands unless the sni
>> However, saying
>>
>> \oo VeryLong.Grob.PropertyToBeChanged = foo
>>
>> for this (and only this) snippet is just fine.
>
> I don't think that it makes sense for snippets to introduce
> convenience shorthands unless the snippet in itself tries is about
> showcasing the shorthand. It detracts
Werner LEMBERG writes:
>>> Because right now LSR is still using this version.
>>
>> Then that means we have to use that oo code in the NR? I am not sure
>> I follow. I'd rather not please.
>
> Right now I'm checking the NR for bad typography in the PDF version,
> which usually means overlong line
Werner LEMBERG writes:
>> oo = #(define-music-function (parser location prop value)
>>(symbol-list? scheme?)
>> #{ \once \override #prop = #value #})
>>
>> should likely work fine in 2.18.
>
> Thanks! Aaron provided this version
>
> oo = #(define-music-function (parser locatio
>> Because right now LSR is still using this version.
>
> Then that means we have to use that oo code in the NR? I am not sure
> I follow. I'd rather not please.
Right now I'm checking the NR for bad typography in the PDF version,
which usually means overlong lines. A lot of snippets are directly
Then that means we have to use that oo code in the NR? I am not sure I
follow. I'd rather not please.
Andrew
On 28/08/2020 1:48 pm, Werner LEMBERG wrote:
I side step the whole thing by having dynamic expanable macros in
the text editor.
But this gives overlong lines, which I want to avoid fo
> oo = #(define-music-function (parser location prop value)
>(symbol-list? scheme?)
> #{ \once \override #prop = #value #})
>
> should likely work fine in 2.18.
Thanks! Aaron provided this version
oo = #(define-music-function (parser location prop value)
(list? sche
> I side step the whole thing by having dynamic expanable macros in
> the text editor.
But this gives overlong lines, which I want to avoid for snippets
taken from the LSR and being part of the NR.
> And why use 2.18?
Because right now LSR is still using this version.
Werner
I side step the whole thing by having dynamic expanable macros in the
text editor.
And why use 2.18?
Andrew
On 28/08/2020 6:10 am, Werner LEMBERG wrote:
Folks,
I wonder whether there is a possibility to have a working equivalent
to
oo = \once\override
so that I can say
\oo foo.bar
Werner LEMBERG writes:
>>> I wonder whether there is a possibility to have a working equivalent
>>> to
>>>
>>> oo = \once\override
>>>
>>> so that I can say
>>>
>>> \oo foo.bar = #'baz .
>>
>> The best you can aim for is
>>
>> \oo foo.bar #'baz
>
> This would be just fine. The thing is to
> Like this, I would imagine:
>
>
> \version "2.18.2"
>
> oo =
> #(define-music-function
> (parser location grob-path value)
> (list? scheme?)
> #{ \once \override $grob-path = #value #})
Great, thanks!
Werner
On 2020-08-27 1:27 pm, David Kastrup wrote:
Werner LEMBERG writes:
Folks,
I wonder whether there is a possibility to have a working equivalent
to
oo = \once\override
so that I can say
\oo foo.bar = #'baz .
It should work with LilyPond 2.18, BTW.
A quick search in the internet didn
>> I wonder whether there is a possibility to have a working equivalent
>> to
>>
>> oo = \once\override
>>
>> so that I can say
>>
>> \oo foo.bar = #'baz .
>
> The best you can aim for is
>
> \oo foo.bar #'baz
This would be just fine. The thing is to replace `\once\override`
with somethi
Werner LEMBERG writes:
> Folks,
>
>
> I wonder whether there is a possibility to have a working equivalent
> to
>
> oo = \once\override
>
> so that I can say
>
> \oo foo.bar = #'baz .
>
> It should work with LilyPond 2.18, BTW.
>
> A quick search in the internet didn't bring something relev
Folks,
I wonder whether there is a possibility to have a working equivalent
to
oo = \once\override
so that I can say
\oo foo.bar = #'baz .
It should work with LilyPond 2.18, BTW.
A quick search in the internet didn't bring something relevant. Help
would be much appreciated.
We
38 matches
Mail list logo
