[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Markup module patch (Issue 2026)

From: Ian Hulin
Subject: Re: Markup module patch (Issue 2026)
Date: Fri, 16 Dec 2011 23:26:31 +0000
User-agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0

On 16/12/11 18:07, David Kastrup wrote:
> Ian Hulin <address@hidden> 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.
No finger-pointing intended.  I'm just frustrated that this rather
brittle subsystem is holding up progress on what I really want to work
on (i.e. fixing issue 2026 so I can crack on with completing 1686.

> 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.
Seconded, but knives?  I do hope it hasn't got *that* unfriendly.
It's more like a game of "hot-potato voleyball". I'm trying to get
away with changing as little of the markup code internals as I can.

>> 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.
Lilypond scoping is implemented using the Guile module system. Each
new Lilypond scope is declared as an anonymous Guile module, and we
use special code provided by Guile V2 (module-export-all!) which we
emulate for Guile V1.8 by declaring it in lily.scm (the Guile team
actually supplied us with the code as we were doing it before in a
rather under-the-counter unsupported manner).  This is done in code by
routine ly_make_module in using a undocumented Guile
routine make-module.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]