Re: Markup module patch (Issue 2026)

[address@hidden]

On Dec 16, 2011, at 6:46 PM, Ian Hulin wrote:

> Hi Han-Wen,
> 
> On 15/12/11 12:48, Han-Wen Nienhuys wrote:
>> On Wed, Dec 14, 2011 at 12:51 AM, Ian Hulin <address@hidden> wrote:
>> 
>>> In order to get the markup stuff to compile or be interpreted
>>> correctly with Guile V2, I had to get the procedures validating the
>>> markup commands to look in a single module at the list where they were
>>> held. So I chose the base (lily) module.
>> 
>>> To keep it consistent, I got
>>> the define-markup-command and define-markup-list-command macros to
>>> push and pop the current Scheme module by doing
>>> (let (prevmod (current-module))
>>>   (existing declaration)
>>>      ...
>> 
>> Does this mean that markup definitions in user code (ie. in .ly files)
>> will be put in the lily module too? How will you prevent definitions
>> from leaking between files?
>> 
> You mean in the case of something like
> $ lilypond gibbon.ly vole.ly aardvark.ly
> where gibbon.ly has
> #(define-markup-command (bananas layout properties markup?) blah ...)
> vole.ly and aardvark.ly would still be able code
> \markup \bananas ...
> and they would pick up the definition from gibbon.ly.
> 
> Mao.  You're right.
> 
>> Why can't the validation procedure look in multiple places?
>> 
> 
> 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 know very little about this whole Guile 2.0 business, but if there were ever 
a time to rewrite the markup code, this'd be it.

It'd be a shame for Ian to do backflips over markups only to have them gutted 
in the future.

Ideally, I would like to see every graphical object in LilyPond be a Grob, the 
Prob class (and maybe even the Paper_score class) eliminated, and 
define-markup-command no longer be a macro but rather a normal function that 
results in the creations of Grobs and overrides to these Grobs.

Does this seem like it's worth it?  It has been on my mind for some time, but 
given that you're at a moment where a lot of code rewriting may need to happen, 
it seems like a good idea to make structural changes now rather than later.

Bertrand and I kicked around this idea back in the day and afterwards I put 
together a little writeup to summarize our discussion (Bertrand - feel free to 
add or subtract as you see fit) - I'll mail that out in a separate mail.

Cheers,
MS