Thomas Morley <thomasmorle...@gmail.com> writes:
> 2017-11-08 23:56 GMT+01:00 David Kastrup <d...@gnu.org>:
>> Thomas Morley <thomasmorle...@gmail.com> writes:
>>
>>> 2017-11-08 23:40 GMT+01:00 David Kastrup <d...@gnu.org>:
>>>> Thomas Morley <thomasmorle...@gmail.com> writes:
>>>>>
>>>>> {
>>>>> \override Fingering #'stencil =
>>>>> #(lambda (grob)
>>>>> (ly:grob-set-property! grob 'stencil
>>>>> (grob-interpret-markup grob #{ \markup \normal-text "foo" #})))
>>>>> a''-1
>>>>> }
>>>>>
>>>>> I doubt many people would have been able to read the error and
>>>>> directly point to the faulty coding.
>>>>
>>>> Assertion failures should not be triggered by users anyway. They point
>>>> to a violation of the program's assumptions severe enough that it makes
>>>> no sense to continue. So this should likely become a programming error
>>>> instead.
>>>>
>>>> You still won't get sensible behavior here since the return value will
>>>> (I think) be wrong, too.
>>>
>>> I'm not that interested in a useful return value, but an (programming)
>>> error-message pointing to the location would be great.
>>> If not possible to point to the location, maybe something like "Can't
>>> set property 'stencil while setting 'stencil".
>>> Well, the wording is not accurate, but you may get the point!?
>>
>> "Property 'stencil changed from inside callback." or something.
>
>
>
> Yeah, that would have been really helpful.
Tracker issue: 5238 (https://sourceforge.net/p/testlilyissues/issues/5238/)
Rietveld issue: 334970043 (https://codereview.appspot.com/334970043)
Issue description:
Callbacks setting properties are programming errors Previously a
callback setting a property led to an assertion failure. That's not
particularly helpful since this is a somewhat easy user error to
make.
--
David Kastrup
_______________________________________________
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
