Re: Edition Engraver master vs refactor override branch: changing bound-details

[Stefano Troncaro]

Oh I see.

For that reason I moved away from using the << ... \\ ... >> construct and
now I use \voices which by the way I find way more suited for my use case
of engraving piano music and then editing it with the edition engraver. I
use only one Voice per Staff, called "main", and spontaneous voices are
called "sub", "subb" for the second simultaneous extra voice, etc., so I
can always reach the main voice with \musicPath PNO.right.Voice.main and
all the other voices with PNO.right.Voice.sub. This way I don't have to
worry about counting them or giving them IDs, it can get confusing in long
scores if you have 20 or more total voices in a staff all named Voice.A,
Voice.B, etc, even when some of them are only active on one or two bars.
And the input files are really easy to read and mentally parse when written
in this way.

Now that I wrote this I think it would be interesting to find out how other
users use the tools to fit their needs and workflows. Lilypond is so open
in this regard.

What I meant to say with this is that this limitation of the Edition
Engraver can be worked around. In fact this could be an interesting
addendum to the guide in the wiki.

El dom., 5 may. 2019 a las 6:31, Jan-Peter Voigt ()
escribió:

> Hi Stefano,
>
> Am 05.05.19 um 06:12 schrieb Stefano Troncaro:
>
> Hi Jan Peter,
>
> I tested the newly merged refactor-override branch a little bit. As far as
> I could tell it seems to be working fine and the problem I described in my
> original post (where there was an error when a grob-property-path consisted
> of a list) is solved.
>
> A minor issue I find is that the Edition Engraver is now printing a lot of
> superfluous warnings of the type "edition-engraver overriden by music!". I
> say superfluous because the overrides are clearly working as intended and
> there is nothing in the music overlapping with the overrides I want the EE
> to make
> However, I've been unable to replicate this problem in small contained
> examples. This happened in projects of some size, and when I try to extract
> the problematic measures to create a self-contained one or two bar example,
> then the warnings are not created anymore. Because of this I hesitated a
> bit about describing the problem, but since the same projects create no
> superfluous warnings when compiled with the current master branch I thought
> it might be useful to tell you about it either way.
>
> If I recall correctly this used to happen some time ago? Maybe it
> reappeared because it was still present in the refactor-override branch.
>
> I'll see if tomorrow I manage to narrow it down and create an example.
>
> I hope this was of some use,
>
> o yes, it is of use. It reminds me of making this log message optional and
> to narrow it down to really affected cases. The problem is that in certain
> cases an override inside the music stream can override an override injected
> by the EE. The problem may not obvious on first sight: Some LilyPond
> constructs inject overrides into the music stream like for example
> simultaneous music (<< .. \\ .. >>). Now when you have such a section of
> simultaneous music and you want to affect stem-direction in Voice "1" the
> EE-override will be overridden on the first moment the simultaneous music
> is introduced.
> I introduced this log message to identify possible cases. IIRC this was
> the main reason to not merge into master yet.
>
> I'll look into it the next days.
>
> Jan-Peter
>
> Stéfano
>
> El sáb., 4 may. 2019 a las 14:13, Stefano Troncaro (<
> stefanotronc...@gmail.com>) escribió:
>
>> Hi Jan Peter, I'll update and let you know if I find any problems with
>> the updated refactor-override branch.
>>
>> Thank you for all your work in the Edition Engraver!
>>
>> El vie., 3 may. 2019 a las 3:37, Jan-Peter Voigt ()
>> escribió:
>>
>>> Hi Stefano,
>>>
>>> a lot of lilypond-unrelated business prevented me working on the
>>> edition-engraver and especially in the refactor-override-branch for quite a
>>> while.
>>> Meanwhile there where some small issues to fix in master so the two
>>> branches diverged.
>>> So the old and stale 'refactor-override-branch' is a development branch
>>> removing and changing code related to \override, \set et al..
>>> Now I merged master into 'refactor-override-branch' so it is up to date
>>> with master.
>>> For now I suggest using the updated branch. I am going to test it soon
>>> so that is fit to be merged into master.
>>> And the next development branch is 'absolute-timing' meant to introduce
>>> anchors and the correct handling of cadenza sections.
>>>
>>> If there are any problems with the 'refactor-override-branch' please let
>>> me know and I am going to fix it asap.
>>>
>>> Jan-Peter
>>>
>>>
>>> Am 30.04.19 um 17:16 schrieb Stefano Troncaro:
>>>
>>> Hi Jan-Peter,
>>>
>>> Sure! Please let me know if you manage to solve it so I can update.
>>>
>>> Thank you!
>>>
>>> El dom., 28 abr. 2019 a las 16:05, Jan-Peter Voigt ()
>>> escribió:
>>>
 Hi Stefano,

Re: Edition Engraver master vs refactor override branch: changing bound-details

[Jan-Peter Voigt]

Hi Stefano,

Am 05.05.19 um 06:12 schrieb Stefano Troncaro:
> Hi Jan Peter,
>
> I tested the newly merged refactor-override branch a little bit. As
> far as I could tell it seems to be working fine and the problem I
> described in my original post (where there was an error when a
> grob-property-path consisted of a list) is solved.
>
> A minor issue I find is that the Edition Engraver is now printing a
> lot of superfluous warnings of the type "edition-engraver overriden by
> music!". I say superfluous because the overrides are clearly working
> as intended and there is nothing in the music overlapping with the
> overrides I want the EE to make
> However, I've been unable to replicate this problem in small contained
> examples. This happened in projects of some size, and when I try to
> extract the problematic measures to create a self-contained one or two
> bar example, then the warnings are not created anymore. Because of
> this I hesitated a bit about describing the problem, but since the
> same projects create no superfluous warnings when compiled with the
> current master branch I thought it might be useful to tell you about
> it either way.
>
> If I recall correctly this used to happen some time ago? Maybe it
> reappeared because it was still present in the refactor-override branch.
>
> I'll see if tomorrow I manage to narrow it down and create an example.
>
> I hope this was of some use,
o yes, it is of use. It reminds me of making this log message optional
and to narrow it down to really affected cases. The problem is that in
certain cases an override inside the music stream can override an
override injected by the EE. The problem may not obvious on first sight:
Some LilyPond constructs inject overrides into the music stream like for
example simultaneous music (<< .. \\ .. >>). Now when you have such a
section of simultaneous music and you want to affect stem-direction in
Voice "1" the EE-override will be overridden on the first moment the
simultaneous music is introduced.
I introduced this log message to identify possible cases. IIRC this was
the main reason to not merge into master yet.

I'll look into it the next days.

Jan-Peter

> Stéfano
>
> El sáb., 4 may. 2019 a las 14:13, Stefano Troncaro
> (mailto:stefanotronc...@gmail.com>>) escribió:
>
> Hi Jan Peter, I'll update and let you know if I find any problems
> with the updated refactor-override branch.
>
> Thank you for all your work in the Edition Engraver!
>
> El vie., 3 may. 2019 a las 3:37, Jan-Peter Voigt ( >) escribió:
>
> Hi Stefano,
>
> a lot of lilypond-unrelated business prevented me working on
> the edition-engraver and especially in the
> refactor-override-branch for quite a while.
> Meanwhile there where some small issues to fix in master so
> the two branches diverged.
> So the old and stale 'refactor-override-branch' is a
> development branch removing and changing code related to
> \override, \set et al..
> Now I merged master into 'refactor-override-branch' so it is
> up to date with master.
> For now I suggest using the updated branch. I am going to test
> it soon so that is fit to be merged into master.
> And the next development branch is 'absolute-timing' meant to
> introduce anchors and the correct handling of cadenza sections.
>
> If there are any problems with the 'refactor-override-branch'
> please let me know and I am going to fix it asap.
>
> Jan-Peter
>
>
> Am 30.04.19 um 17:16 schrieb Stefano Troncaro:
>> Hi Jan-Peter,
>>
>> Sure! Please let me know if you manage to solve it so I can
>> update.
>>
>> Thank you!
>>
>> El dom., 28 abr. 2019 a las 16:05, Jan-Peter Voigt
>> (mailto:jp.vo...@gmx.de>>) escribió:
>>
>> Hi Stefano,
>>
>> sorry for the delay. I've been away for several days.
>> I have to look into this deeper ... I guess it is related
>> to the
>> grob-property-path 'bound-details.left.text'.
>> Hopefully I can solve this issue soon.
>>
>> Best
>> Jan-Peter
>>
>> Am 21.04.19 um 20:42 schrieb Stefano Troncaro:
>> > Hi all, long time since I posted here, hope you all
>> have been well!
>> >
>> > While using the Edition Engraver today I noticed that
>> the following
>> > override works in the old refactor override branch,
>> while on the
>> > current master it prints a textless spanner and a warning:
>> >
>> > \version "2.19.80" \include "oll-core/package.ily"
>> \loadPackage edition-engraver \consistToContexts
>> #edition-engraver Voice \addEdition test \editionMod test
>> 1 0 Voice.A { \override
>>

Re: Edition Engraver master vs refactor override branch: changing bound-details

[Stefano Troncaro]

Hi Jan Peter,

I tested the newly merged refactor-override branch a little bit. As far as
I could tell it seems to be working fine and the problem I described in my
original post (where there was an error when a grob-property-path consisted
of a list) is solved.

A minor issue I find is that the Edition Engraver is now printing a lot of
superfluous warnings of the type "edition-engraver overriden by music!". I
say superfluous because the overrides are clearly working as intended and
there is nothing in the music overlapping with the overrides I want the EE
to make
However, I've been unable to replicate this problem in small contained
examples. This happened in projects of some size, and when I try to extract
the problematic measures to create a self-contained one or two bar example,
then the warnings are not created anymore. Because of this I hesitated a
bit about describing the problem, but since the same projects create no
superfluous warnings when compiled with the current master branch I thought
it might be useful to tell you about it either way.

If I recall correctly this used to happen some time ago? Maybe it
reappeared because it was still present in the refactor-override branch.

I'll see if tomorrow I manage to narrow it down and create an example.

I hope this was of some use,
Stéfano

El sáb., 4 may. 2019 a las 14:13, Stefano Troncaro (<
stefanotronc...@gmail.com>) escribió:

> Hi Jan Peter, I'll update and let you know if I find any problems with the
> updated refactor-override branch.
>
> Thank you for all your work in the Edition Engraver!
>
> El vie., 3 may. 2019 a las 3:37, Jan-Peter Voigt ()
> escribió:
>
>> Hi Stefano,
>>
>> a lot of lilypond-unrelated business prevented me working on the
>> edition-engraver and especially in the refactor-override-branch for quite a
>> while.
>> Meanwhile there where some small issues to fix in master so the two
>> branches diverged.
>> So the old and stale 'refactor-override-branch' is a development branch
>> removing and changing code related to \override, \set et al..
>> Now I merged master into 'refactor-override-branch' so it is up to date
>> with master.
>> For now I suggest using the updated branch. I am going to test it soon so
>> that is fit to be merged into master.
>> And the next development branch is 'absolute-timing' meant to introduce
>> anchors and the correct handling of cadenza sections.
>>
>> If there are any problems with the 'refactor-override-branch' please let
>> me know and I am going to fix it asap.
>>
>> Jan-Peter
>>
>>
>> Am 30.04.19 um 17:16 schrieb Stefano Troncaro:
>>
>> Hi Jan-Peter,
>>
>> Sure! Please let me know if you manage to solve it so I can update.
>>
>> Thank you!
>>
>> El dom., 28 abr. 2019 a las 16:05, Jan-Peter Voigt ()
>> escribió:
>>
>>> Hi Stefano,
>>>
>>> sorry for the delay. I've been away for several days.
>>> I have to look into this deeper ... I guess it is related to the
>>> grob-property-path 'bound-details.left.text'.
>>> Hopefully I can solve this issue soon.
>>>
>>> Best
>>> Jan-Peter
>>>
>>> Am 21.04.19 um 20:42 schrieb Stefano Troncaro:
>>> > Hi all, long time since I posted here, hope you all have been well!
>>> >
>>> > While using the Edition Engraver today I noticed that the following
>>> > override works in the old refactor override branch, while on the
>>> > current master it prints a textless spanner and a warning:
>>> >
>>> > \version "2.19.80" \include "oll-core/package.ily" \loadPackage
>>> edition-engraver \consistToContexts #edition-engraver Voice \addEdition
>>> test \editionMod test 1 0 Voice.A { \override
>>> TextSpanner.bound-details.left.text = "span this" <>\startTextSpan }
>>> \editionMod test 2 3/4 Voice.A \stopTextSpan \new Staff { \new Voice
>>> \relative { c' d e f g a b c } }
>>> >
>>> > Said warning is
>>> >
>>> > warning: type check for `bound-details' failed; value `"span this"'
>>> > must be of type `list'
>>> >
>>> > In the current master I could set this like this:
>>> > \override TextSpanner.bound-details = #'((left . ((text . "span
>>> this"
>>> > but this has the undesirable effect of resetting all the other
>>> > settings of the bound-details alist
>>> >
>>> > Without having been able to dive down into the code, this looks like a
>>> > simple issue with type checking, but I realize this may have been
>>> > implemented this way to circumvent other problems.
>>> >
>>> > So, how can I achieve this with the current master? Or should I go
>>> > back to using the earlier branch until this is solved?
>>> >
>>> > Thanks for your help,
>>> > Stéfano
>>> >
>>> > ___
>>> > lilypond-user mailing list
>>> > lilypond-user@gnu.org
>>> > https://lists.gnu.org/mailman/listinfo/lilypond-user
>>>
>>>
>>> ___
>>> lilypond-user mailing list
>>> lilypond-user@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/lilypond-user
>>>
>>
>>
___
lilypond-user 

Re: Edition Engraver master vs refactor override branch: changing bound-details

[Stefano Troncaro]

Hi Jan Peter, I'll update and let you know if I find any problems with the
updated refactor-override branch.

Thank you for all your work in the Edition Engraver!

El vie., 3 may. 2019 a las 3:37, Jan-Peter Voigt ()
escribió:

> Hi Stefano,
>
> a lot of lilypond-unrelated business prevented me working on the
> edition-engraver and especially in the refactor-override-branch for quite a
> while.
> Meanwhile there where some small issues to fix in master so the two
> branches diverged.
> So the old and stale 'refactor-override-branch' is a development branch
> removing and changing code related to \override, \set et al..
> Now I merged master into 'refactor-override-branch' so it is up to date
> with master.
> For now I suggest using the updated branch. I am going to test it soon so
> that is fit to be merged into master.
> And the next development branch is 'absolute-timing' meant to introduce
> anchors and the correct handling of cadenza sections.
>
> If there are any problems with the 'refactor-override-branch' please let
> me know and I am going to fix it asap.
>
> Jan-Peter
>
>
> Am 30.04.19 um 17:16 schrieb Stefano Troncaro:
>
> Hi Jan-Peter,
>
> Sure! Please let me know if you manage to solve it so I can update.
>
> Thank you!
>
> El dom., 28 abr. 2019 a las 16:05, Jan-Peter Voigt ()
> escribió:
>
>> Hi Stefano,
>>
>> sorry for the delay. I've been away for several days.
>> I have to look into this deeper ... I guess it is related to the
>> grob-property-path 'bound-details.left.text'.
>> Hopefully I can solve this issue soon.
>>
>> Best
>> Jan-Peter
>>
>> Am 21.04.19 um 20:42 schrieb Stefano Troncaro:
>> > Hi all, long time since I posted here, hope you all have been well!
>> >
>> > While using the Edition Engraver today I noticed that the following
>> > override works in the old refactor override branch, while on the
>> > current master it prints a textless spanner and a warning:
>> >
>> > \version "2.19.80" \include "oll-core/package.ily" \loadPackage
>> edition-engraver \consistToContexts #edition-engraver Voice \addEdition
>> test \editionMod test 1 0 Voice.A { \override
>> TextSpanner.bound-details.left.text = "span this" <>\startTextSpan }
>> \editionMod test 2 3/4 Voice.A \stopTextSpan \new Staff { \new Voice
>> \relative { c' d e f g a b c } }
>> >
>> > Said warning is
>> >
>> > warning: type check for `bound-details' failed; value `"span this"'
>> > must be of type `list'
>> >
>> > In the current master I could set this like this:
>> > \override TextSpanner.bound-details = #'((left . ((text . "span
>> this"
>> > but this has the undesirable effect of resetting all the other
>> > settings of the bound-details alist
>> >
>> > Without having been able to dive down into the code, this looks like a
>> > simple issue with type checking, but I realize this may have been
>> > implemented this way to circumvent other problems.
>> >
>> > So, how can I achieve this with the current master? Or should I go
>> > back to using the earlier branch until this is solved?
>> >
>> > Thanks for your help,
>> > Stéfano
>> >
>> > ___
>> > lilypond-user mailing list
>> > lilypond-user@gnu.org
>> > https://lists.gnu.org/mailman/listinfo/lilypond-user
>>
>>
>> ___
>> lilypond-user mailing list
>> lilypond-user@gnu.org
>> https://lists.gnu.org/mailman/listinfo/lilypond-user
>>
>
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Edition Engraver master vs refactor override branch: changing bound-details

[Jan-Peter Voigt]

Hi Stefano,

a lot of lilypond-unrelated business prevented me working on the
edition-engraver and especially in the refactor-override-branch for
quite a while.
Meanwhile there where some small issues to fix in master so the two
branches diverged.
So the old and stale 'refactor-override-branch' is a development branch
removing and changing code related to \override, \set et al..
Now I merged master into 'refactor-override-branch' so it is up to date
with master.
For now I suggest using the updated branch. I am going to test it soon
so that is fit to be merged into master.
And the next development branch is 'absolute-timing' meant to introduce
anchors and the correct handling of cadenza sections.

If there are any problems with the 'refactor-override-branch' please let
me know and I am going to fix it asap.

Jan-Peter


Am 30.04.19 um 17:16 schrieb Stefano Troncaro:
> Hi Jan-Peter,
>
> Sure! Please let me know if you manage to solve it so I can update.
>
> Thank you!
>
> El dom., 28 abr. 2019 a las 16:05, Jan-Peter Voigt ( >) escribió:
>
> Hi Stefano,
>
> sorry for the delay. I've been away for several days.
> I have to look into this deeper ... I guess it is related to the
> grob-property-path 'bound-details.left.text'.
> Hopefully I can solve this issue soon.
>
> Best
> Jan-Peter
>
> Am 21.04.19 um 20:42 schrieb Stefano Troncaro:
> > Hi all, long time since I posted here, hope you all have been well!
> >
> > While using the Edition Engraver today I noticed that the following
> > override works in the old refactor override branch, while on the
> > current master it prints a textless spanner and a warning:
> >
> > \version "2.19.80" \include "oll-core/package.ily" \loadPackage
> edition-engraver \consistToContexts #edition-engraver Voice
> \addEdition test \editionMod test 1 0 Voice.A { \override
> TextSpanner.bound-details.left.text = "span this" <>\startTextSpan
> } \editionMod test 2 3/4 Voice.A \stopTextSpan \new Staff { \new
> Voice \relative { c' d e f g a b c } }
> >
> > Said warning is
> >
> > warning: type check for `bound-details' failed; value `"span this"'
> > must be of type `list'
> >
> > In the current master I could set this like this:
> > \override TextSpanner.bound-details = #'((left . ((text . "span
> this"
> > but this has the undesirable effect of resetting all the other
> > settings of the bound-details alist
> >
> > Without having been able to dive down into the code, this looks
> like a
> > simple issue with type checking, but I realize this may have been
> > implemented this way to circumvent other problems.
> >
> > So, how can I achieve this with the current master? Or should I go
> > back to using the earlier branch until this is solved?
> >
> > Thanks for your help,
> > Stéfano
> >
> > ___
> > lilypond-user mailing list
> > lilypond-user@gnu.org 
> > https://lists.gnu.org/mailman/listinfo/lilypond-user
>
>
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org 
> https://lists.gnu.org/mailman/listinfo/lilypond-user
>

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

Re: Edition Engraver master vs refactor override branch: changing bound-details

[Stefano Troncaro]

Hi Jan-Peter,

Sure! Please let me know if you manage to solve it so I can update.

Thank you!

El dom., 28 abr. 2019 a las 16:05, Jan-Peter Voigt ()
escribió:

> Hi Stefano,
>
> sorry for the delay. I've been away for several days.
> I have to look into this deeper ... I guess it is related to the
> grob-property-path 'bound-details.left.text'.
> Hopefully I can solve this issue soon.
>
> Best
> Jan-Peter
>
> Am 21.04.19 um 20:42 schrieb Stefano Troncaro:
> > Hi all, long time since I posted here, hope you all have been well!
> >
> > While using the Edition Engraver today I noticed that the following
> > override works in the old refactor override branch, while on the
> > current master it prints a textless spanner and a warning:
> >
> > \version "2.19.80" \include "oll-core/package.ily" \loadPackage
> edition-engraver \consistToContexts #edition-engraver Voice \addEdition
> test \editionMod test 1 0 Voice.A { \override
> TextSpanner.bound-details.left.text = "span this" <>\startTextSpan }
> \editionMod test 2 3/4 Voice.A \stopTextSpan \new Staff { \new Voice
> \relative { c' d e f g a b c } }
> >
> > Said warning is
> >
> > warning: type check for `bound-details' failed; value `"span this"'
> > must be of type `list'
> >
> > In the current master I could set this like this:
> > \override TextSpanner.bound-details = #'((left . ((text . "span this"
> > but this has the undesirable effect of resetting all the other
> > settings of the bound-details alist
> >
> > Without having been able to dive down into the code, this looks like a
> > simple issue with type checking, but I realize this may have been
> > implemented this way to circumvent other problems.
> >
> > So, how can I achieve this with the current master? Or should I go
> > back to using the earlier branch until this is solved?
> >
> > Thanks for your help,
> > Stéfano
> >
> > ___
> > lilypond-user mailing list
> > lilypond-user@gnu.org
> > https://lists.gnu.org/mailman/listinfo/lilypond-user
>
>
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Edition Engraver master vs refactor override branch: changing bound-details

[Jan-Peter Voigt]

Hi Stefano,

sorry for the delay. I've been away for several days.
I have to look into this deeper ... I guess it is related to the
grob-property-path 'bound-details.left.text'.
Hopefully I can solve this issue soon.

Best
Jan-Peter

Am 21.04.19 um 20:42 schrieb Stefano Troncaro:
> Hi all, long time since I posted here, hope you all have been well!
>
> While using the Edition Engraver today I noticed that the following
> override works in the old refactor override branch, while on the
> current master it prints a textless spanner and a warning:
>
> \version "2.19.80" \include "oll-core/package.ily" \loadPackage 
> edition-engraver \consistToContexts #edition-engraver Voice \addEdition test 
> \editionMod test 1 0 Voice.A { \override TextSpanner.bound-details.left.text 
> = "span this" <>\startTextSpan } \editionMod test 2 3/4 Voice.A \stopTextSpan 
> \new Staff { \new Voice \relative { c' d e f g a b c } }
>
> Said warning is
>
> warning: type check for `bound-details' failed; value `"span this"'
> must be of type `list'
>
> In the current master I could set this like this:
> \override TextSpanner.bound-details = #'((left . ((text . "span this"
> but this has the undesirable effect of resetting all the other
> settings of the bound-details alist
>
> Without having been able to dive down into the code, this looks like a
> simple issue with type checking, but I realize this may have been
> implemented this way to circumvent other problems.
>
> So, how can I achieve this with the current master? Or should I go
> back to using the earlier branch until this is solved?
>
> Thanks for your help,
> Stéfano
>
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user


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

Edition Engraver master vs refactor override branch: changing bound-details

[Stefano Troncaro]

Hi all, long time since I posted here, hope you all have been well!

While using the Edition Engraver today I noticed that the following
override works in the old refactor override branch, while on the current
master it prints a textless spanner and a warning:

\version "2.19.80"
\include "oll-core/package.ily"\loadPackage edition-engraver
\consistToContexts #edition-engraver Voice\addEdition test
\editionMod test 1 0 Voice.A {
  \override TextSpanner.bound-details.left.text = "span this"
  <>\startTextSpan}\editionMod test 2 3/4 Voice.A \stopTextSpan

\new Staff {
  \new Voice \relative {
c' d e f g a b c
  }
}



Said warning is

warning: type check for `bound-details' failed; value `"span this"' must be
of type `list'


In the current master I could set this like this:
\override TextSpanner.bound-details = #'((left . ((text . "span this"
but this has the undesirable effect of resetting all the other settings of
the bound-details alist

Without having been able to dive down into the code, this looks like a
simple issue with type checking, but I realize this may have been
implemented this way to circumvent other problems.

So, how can I achieve this with the current master? Or should I go back to
using the earlier branch until this is solved?

Thanks for your help,
Stéfano
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user