macro for \once\override

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

macro for \once\override

Werner LEMBERG

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.


    Werner

Reply | Threaded
Open this post in threaded view
|

Re: macro for \once\override

David Kastrup
Werner LEMBERG <[hidden email]> 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 relevant.

No, and not in 2.20 either.  The best you can aim for is

\oo foo.bar #'baz

(which is similar to \tweak syntax) but the equals sign is a syntactic
entity that you cannot sensibly hoover up in a music function.  And if
you do something appalling, like letting oo inject "\\once \\override "
into the input stream, it's very likely that it will break down in more
complex uses than when just writing it into immediate code.

> Help would be much appreciated.


--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: macro for \once\override

Werner LEMBERG

>> 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 something shorter.


    Werner

Reply | Threaded
Open this post in threaded view
|

Re: macro for \once\override

Aaron Hill
In reply to this post by David Kastrup
On 2020-08-27 1:27 pm, David Kastrup wrote:

> Werner LEMBERG <[hidden email]> 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 relevant.
>
> No, and not in 2.20 either.  The best you can aim for is
>
> \oo foo.bar #'baz

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 #})

{ b'4 \oo NoteHead.color #red g'4 a'2 }
%%%%


-- Aaron Hill

Reply | Threaded
Open this post in threaded view
|

Re: macro for \once\override

Werner LEMBERG
> 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

Reply | Threaded
Open this post in threaded view
|

Re: macro for \once\override

David Kastrup
In reply to this post by Werner LEMBERG
Werner LEMBERG <[hidden email]> 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 replace `\once\override`
> with something shorter.

oo = #(define-music-function (parser location prop value) (symbol-list? scheme?)
        #{ \once \override #prop = #value #})

should likely work fine in 2.18.

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: macro for \once\override

Andrew Bernard
In reply to this post by Werner LEMBERG
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 = #'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.
>
>
>      Werner
>

Reply | Threaded
Open this post in threaded view
|

Re: macro for \once\override

Werner LEMBERG

> 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

Reply | Threaded
Open this post in threaded view
|

Re: macro for \once\override

Werner LEMBERG
In reply to this post by David Kastrup

> 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? scheme?)
          #{ \once \override $prop = #value #})

and I wonder which one is better...


    Werer

Reply | Threaded
Open this post in threaded view
|

Re: macro for \once\override

Andrew Bernard
In reply to this post by Werner LEMBERG
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 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

Reply | Threaded
Open this post in threaded view
|

Re: macro for \once\override

Werner LEMBERG
>> 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
imported from the LSR; they are typeset unmodified.  One of the
snippets has a bunch of

  \once\overvide VeryLong.Grob.PropertyToBeChanged = foo

Changing them to

  \once\overvide
    VeryLong.Grob.PropertyToBeChanged = foo

looks bad.  However, saying

  \oo VeryLong.Grob.PropertyToBeChanged = foo

for this (and only this) snippet is just fine.


    Werner

Reply | Threaded
Open this post in threaded view
|

Re: macro for \once\override

David Kastrup
In reply to this post by Werner LEMBERG
Werner LEMBERG <[hidden email]> 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 location prop value)
>          (list? scheme?)
>           #{ \once \override $prop = #value #})
>
> and I wonder which one is better...

Well, I prefer not investing the overhead of $ when # is sufficient, and
I prefer using predicates that are specific enough to lead to error
messages at the place where the wrong input is rather than triggering
followup errors.

Given correct input, they should do the same.

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: macro for \once\override

David Kastrup
In reply to this post by Werner LEMBERG
Werner LEMBERG <[hidden email]> 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 lines.  A lot of snippets are directly
> imported from the LSR; they are typeset unmodified.  One of the
> snippets has a bunch of
>
>   \once\overvide VeryLong.Grob.PropertyToBeChanged = foo
>
> Changing them to
>
>   \once\overvide
>     VeryLong.Grob.PropertyToBeChanged = foo
>
> looks bad.  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 from the content.

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: macro for \once\override

Werner LEMBERG
>> 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 from the content.

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 simple enough for a snippet.


    Werner

Reply | Threaded
Open this post in threaded view
|

Re: macro for \once\override

Carl Sorensen


On Fri, Aug 28, 2020 at 8:52 AM Werner LEMBERG <[hidden email]> 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 snippet in itself tries is about
> showcasing the shorthand.  It detracts from the content.

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 simple enough for a snippet.

My preference is the one that you said is inappropriate:

\once \override
  Very.Long.Grob.PropertyToBeChanged = foo 

If we introduce oo, then that adds extra lines to the snippet, and it confuses the override (which is the purpose of the snippet) with the convenience function (which is not necessary for the operation of the snippet).

I think that the benefit of the improvement in the typography is outweighed by the increased difficulty of understanding the snippet.

Thanks,

Carl
Reply | Threaded
Open this post in threaded view
|

Re: macro for \once\override

David Kastrup
In reply to this post by Werner LEMBERG
Werner LEMBERG <[hidden email]> 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
>> showcasing the shorthand.  It detracts from the content.
>
> 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.

> 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 simple enough for a snippet.

I find a line wrap quite less of a distraction.

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: macro for \once\override

Werner LEMBERG
In reply to this post by Carl Sorensen

>> 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 simple enough for a snippet.
>>
>
> My preference is the one that you said is inappropriate:
>
> \once \override
>   Very.Long.Grob.PropertyToBeChanged = foo
>
> If we introduce oo, then that adds extra lines to the snippet, and
> it confuses the override (which is the purpose of the snippet) with
> the convenience function (which is not necessary for the operation
> of the snippet).

If you have to split 20 very long `\once\override` line this way, it's
(a) very hard to read, and (b) much longer than the few lines
introducing the little function.

> I think that the benefit of the improvement in the typography is
> outweighed by the increased difficulty of understanding the snippet.

I disagree.  There are snippets with *extremely* sophisticated Scheme
code.  What I'm going to introduce is very basic.


    Werner

Reply | Threaded
Open this post in threaded view
|

Re: macro for \once\override

Werner LEMBERG
In reply to this post by David Kastrup

>> 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 have
some trust in my decision...


    Werner

Reply | Threaded
Open this post in threaded view
|

Re: macro for \once\override

David Kastrup
Werner LEMBERG <[hidden email]> 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 reduces legibility I hope you have
> some trust in my decision...

Maybe

\void \displayLilyMusic
\once
\propertyTweak color #red
\propertyTweak font-size #3
\propertyTweak direction #UP Voice.Slur

helps?

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: macro for \once\override

Andrew Bernard
In reply to this post by Werner LEMBERG
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 this.


Andrew


On 29/08/2020 5:46 am, Werner LEMBERG wrote:
>>> 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 have
> some trust in my decision...
>
>
>      Werner

12