[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Markup module patch (Issue 2026)
From: |
David Kastrup |
Subject: |
Re: Markup module patch (Issue 2026) |
Date: |
Fri, 16 Dec 2011 19:14:14 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) |
"address@hidden" <address@hidden> writes:
> 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.
Normal function: problem with that is that we have separate name spaces
for Lilypond identifiers and markup functions (but not variables
containing markups). Those are currently implemented by tacking
"-markup" to the defined names in the define-markup-command macro.
Turning define-markup-command into a function with the use patterns of
define-music-function would for that reason not be feasible.
> 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.
It certainly sounds like Ian's work is not of the kind we want to have
to do twice. I doubt, however, that we can complete a design that would
allow us to not have to do it at all in a useful time frame.
--
David Kastrup
Re: Markup module patch (Issue 2026), Han-Wen Nienhuys, 2011/12/14