Ian Hulin <i...@hulin.org.uk> writes:
> Because this means serious fiddling with the maoing markup code. I
> really hope you didn't write it because I agree with David, it's a
> fetid pile of Dingo's kidneys to maintain, and I fear it'll take me a
> lo-o-o-ong time and much cursing and swearing to change it.
I actually extended it somewhat at one time. I have stated on this list
that I hate working with C++ and am working hard to make it possible to
avoid that. As a result, you'll see that the vast majority of my work
is on the C++ code base. In a similar vein, you will find my
handwriting in the markup code. But I did not start it.
If #{ \markup ... #} were evaluated at compile time, I would likely
already have set out to obliterate the markup macro altogether and we
would not be slashing with knives at each other for the sake of not
needing to touch this code implementing its own language and system
between LilyPond and Guile ever again.
> It'll mean trying to find a way of getting compile-markup-expression
> to look in a list both in the current module, and then falling back to
> the (lily) module (where all the base code markup commands from
> define-markup-commands.scm will be) before failing the validation.
Can you explain what modules have to do with it? You make it sound as
if every source file needed to end up in its own module except when
taking special measures. That sounds quite inconvenient for working
with projects distributed among multiple Lilypond files.
--
David Kastrup
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
