Hi Han-Wen,
Sorry for taking a while to answer this but I've been caught up in the
normal teacher end-of-Christmas-term insanity. . .
On 14/12/11 12:11, Han-Wen Nienhuys wrote:
> On Tue, Dec 13, 2011 at 5:56 PM, Ian Hulin <i...@hulin.org.uk>
> wrote:
>
>> I pulled out and tested the examples in separate .ly file and
>> the format that fails is #(define-markup-command (double-box
>> layout props text) (markup?) "Draw a double box around text."
>> (interpret-markup layout props #{\markup \override #'(box-padding
>> . 0.4) \box \override #'(box-padding . 0.6) \box { $text }#}))
>> \markup \double-box A
>
> Since the person writing the code is writing Scheme already,
> requiring the inner markups to be in Scheme is a reasonable
> restriction, IMO. That said, it would be nice if #{ #} could be
> made to work, but I not enough insight into how it works.
>
> What is the rationale for putting the markups in a separate
> module?
>
Basically, it boils down to "hygiene".
Guile V2 insists on some thing, particularly macros being defined
before they are used.
When Patrick M. first tried out using Lily with Guile 2, the only way
we could use it was by relying on the equivalent of the Guile
--auto-compile option.
During initialization on the first pass through lily.scm, when we're
building the (lily) module, we got an awful lot of barfs from Guile
that various things, almost always from the markup stuff were unbound
variables. We could code round this by fiddling with the order of
loading the component .scm files in the list for processing by
ly:load, and sometimes by splitting out bits of a file (e.g. migrating
bits of markup.scm -> markup-macros.scm. We did this for one round
round of changes in 2.15, and it kinda worked - e.g. Jan was able to
get schekkers-list to run up a prototype.
However, I felt this was a potential maintainability swamp: the
search-order could easily need changing again because some developer
somewhere wanted to change one of the component modules, i.e. somebody
could do a perfectly respectable and well-behaved change in Lily with
Guile V1.8, and it would meanwhile blow up that version of lily.scm in
Guile V2 without even knowing it.
So it seemed to me the neatest way of avoiding this was to make all
the markup macros and procedures live in their own module, to be
referenced via (use-modules (scm markup-facility-defs)) in the lily
module, and then all the component *.scm files would have the markup
definitions available when the (lily) module was being built, whatever
position its source file occupied in the load list for ly:load in
lily.scm.
I know you have another query about forcing the markup definitions
into the (lily) module, but I'll talk about that in a separate post.
Cheers,
Ian
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
