Re: guilev2 problem (user-markup-command sometimes not accepted)

[David Kastrup]

Thomas Morley <address@hidden> writes:

> Am So., 11. Nov. 2018 um 21:14 Uhr schrieb David Kastrup <address@hidden>:
>>
>> David Kastrup <address@hidden> writes:
>>
>> > I think that Guilev2 may do the syntax form expansion concerning
>> > "markup" before executing the define-markup-command when both are
>> > contained in one begin form.  Macros are executed a bit differently in
>> > Guilev2 than in Guilev1.
>
> Followup questions:
> Is this fixable?

Unlikely.  Macro expansion and execution are different phases in
Guilev2.

> If yes, it is worth the effort?
>
>> The markup macro is a piece of crock anyway.  Use
>> (display-scheme-music (make-dummy-markup "foo"))
>> or
>> (display-scheme-music #{ \markup \dummy foo #})
>> here to get out of that predicament.
>
> Yep, works.
> Part of the problem is I have only a vague guess where in our source
> which syntax possibility regarding markup is made available.
>
> I _think_ 'make-dummy-markup' and 'dummy-markup' is done with
> (defmacro-public define-markup-command ...) from markup-macros,scm.

Yes.

> Though not sure about (markup #:dummy ...), where is it made
> available?

The markup macro is defined at the top of scm/markup.scm .  It
references the various markup predicates.  Guilev2 expands it at a time
in your example where those predicates are not yet defined.

> The error "Not a markup command: ..." seems to come from (define
> (compile-markup-expression expr) ...) triggered by (define
> (lookup-markup-command-aux symbol) ...) which looks at
> (current-module).
> As far as I can tell 'lookup-markup-command-aux' searches the module
> for 'dummy-markup', without success.
>
> So the guess is for guilev2 'define-markup-command ' is not done for
> 'dummy', when 'lookup-markup-command-aux' starts?
> Why does 'make-dummy-markup' work then?

Because it only compiles a reference to the symbol binding of
make-dummy-markup.  That the symbol gets its value later is not a
problem.  That's the reason most of Guilev2's separate
read/compile+macroexpand/execute phases work fine even when some stuff
has been compiled already that only gets defined in the "execute" phase:
the compiler puts in place-holders.  When macro expansion does not rely
on anything defined in the execution phase, that's fine.

If we wanted to be doing that, the markup macro would need to postpone
more work until later.

-- 
David Kastrup