David Kastrup <d...@gnu.org> writes:
> Thomas Morley <thomasmorle...@gmail.com> writes:
>
>> 2018-02-03 23:21 GMT+01:00 David Kastrup <d...@gnu.org>:
>>
>>>
>>> Ok, then it's the primitive-eval crapping out. parser.yy has
>>>
>>> | markup_mode_word '=' identifier_init
>>> {
>>> if (scm_is_false (Lily::markup_function_p ($3)))
>>> {
>>> parser->parser_error (@3, _ ("Not a markup
>>> function"));
>>> } else {
>>> scm_primitive_eval
>>> (scm_list_3
>>> (Lily::define_markup_command,
>>> scm_string_to_symbol ($1),
>>> ly_quote_scm ($3)));
>>> }
>>> $$ = SCM_UNSPECIFIED;
>>> }
>>> ;
>>>
>>> So basically
>>
>> Compiling a file with nothing else then:
>>
>>> #(primitive-eval (list define-markup-command 'bold-red
>>> #{ \markup \bold \with-color #red \etc #}))
>>
>> returns:
>>
>> error: GUILE signaled an error for the expression beginning here
>> #
>> (primitive-eval (list define-markup-command 'bold-red
>> source expression failed to match any pattern
>> fatal error: failed files: "atest-70.ly"
>
> Ugh. Ok, I think I got this. I'll split define-markup-command into a
> macro just calling an internal function, and I'll use the internal
> function inside of the parser. Calling macros from C++ seems to be a
> bad idea.
Huh. Not so simple: there are a few define-public called with
constructed names. I'll have to see what kind of non-syntax equivalents
are available for those. Will take a few days because I have to do
something else tomorrow urgently.
--
David Kastrup
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
