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 (<jp.vo...@gmx.de>)
> 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 (<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
>>> 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
