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: Wed, 14 Dec 2011 00:42:42 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux)

Carl Sorensen <address@hidden> writes:

> On 12/13/11 12:56 PM, "Ian Hulin" <address@hidden> wrote:
>
>>Hi all,
>>The patch had to get pulled from staging as although it passed reg.
>>tests it wouldn't compile the doc.  I can easily fix the snippet in
>>/Documentation/snippets/three-sided-box.ly,

So this patch has more than one issue.

>>but this leaves one more problem in the docs, this time in
>>/extending/.
>>
>>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
>>
>>but
>>#(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
>>
>>works fine.  This is not restricted to the double-box thing, it's
>>general to doing
>>interpret-markup #{ \markup \markup-command #'par ... #} within a
>>#(define-markup-command ...  ) block.  I'd like to deprecate this as I
>>think it's nasty, smelly, evil and kludgy and ask that users use
>>
>>interpret-markup ( markup #:markup-command 'par ... ) instead.
>>
>>We'd mark this as such in NEWS, meanwhile taking out the offending
>>examples from /extending/.
>>
>>WDYT?
>
> I think that David Kastrup is working like crazy to make #{ #} work very
> well.  Before we give up and put an arbitrary restriction, we ought to
> give him a chance to see if he can solve the problem.
>
> If he can't, I support your proposal.  But I expect that he will identify
> and fix the problem.

A bit more perspective.  Whose work broke the doc build?  Mine or Ian's?
Since Ian's work broke existing functionality (functionality that
contributes considerable to making markup functions accessible to mere
mortals), does his use of enough invectives really mean that _I_ have to
identify and fix the shortcomings of his patch without him bothering to
analyze the effects of his own work?  Or have previous work of mine
ripped out of Lilypond?

Does that mean that if I use enough curse words, I don't need to cater
for compatibility in my future work?  I am free to remove functionality
without replacement?

In my opinion, Ian needs to come up with a more useful analysis of the
problems of _his_ code rather than calling other people's work names.
"Let's just throw everything half-baked at David with a few invectives
as garnishment and punish the Lilypond community if he does not sort it
out immediately" is shabby.

-- 
David Kastrup




reply via email to

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