lilypond-devel
[Top][All Lists]
Advanced

[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




reply via email to

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