define-markup-command-internal -> module-define-markup-command!

define-markup-command-internal -> module-define-markup-command!

Tangible benefits of this approach are not all that clear, and it
doesn't cover define-markup-list-command in the current form either,
so it warrants more work before committing or even deciding to commit.
Particularly so since for convenience it reverts a previous patch
combining the internals of define-markup-command and
define-markup-list-command, in order to illustrate the approach just
on the former.

However, it works and provides a basis for discussion.  The principal
idea is to provide a version of define-markup-command that is not
specific to the current module and not a macro, in a similar vein to
how module-define!  complements define , and use this in the parser
rather than the previous somewhat fuzzier
define-markup-command-internal .

Additional commits:

Add Lily_lexer::current_scope () function


Revert "Express define-markup-list-command-internal using define-markup-command-internal"

This reverts commit 9f1683921621b612b94080d506ee317b058b29c8.

[hanwenn, 2020-05-08 17:12:41]

I don't understand how this approach could ever help byte-compiling the markup
scheme files. This still uses module-define! , so the guile2 compilation step
will be oblivious to  markup functions.

[dak, 2020-05-08 17:30:10]

On 2020/05/08 17:12:41, hanwenn wrote:
> I don't understand how this approach could ever help byte-compiling the markup
> scheme files. This still uses module-define! , so the guile2 compilation step
> will be oblivious to  markup functions.

It makes it easier to create specific different behavior for byte-compilation
using eval-when.