Ian Hulin <i...@hulin.org.uk> writes:
> 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, 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
Care to explain why being able to use the same syntax as one uses in the
main document is nasty, smelly, evil and kludgy? Should we disallow
\markup syntax in the main document as well?
> 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 there is nothing much out of the ordinary happening when
the above command is being run, so it is quite likely that we'll get the
same kind of breakage in other situations.
If I call
lilypond scheme-sandbox
and enter
(let ((text "xxx"))
#{ \markup \override #'(box-padding . 0.4) \box
\override #'(box-padding . 0.6) \box { $text }#})
I get
(#<procedure line-markup (layout props args)> ((#<procedure
override-markup (layout props new-prop arg)> (box-padding . 0.4)
(#<procedure box-markup (layout props arg)> (#<procedure override-markup
(layout props new-prop arg)> (box-padding . 0.6) (#<procedure box-markup
(layout props arg)> "xxx"))))))
as result which is perfectly reasonable and does not expose the user to
non-Lilypond syntax, let alone macro expansion.
Since you are the resident expert on Guile v2, it would be nice if you
explained just what in Guile v2 happens to turn this into something
nasty, smelly, evil and kludgy.
It is _exactly_ what the parser will deliver for this particular markup
also in the main document, so if it breaks in #{ ... #}, it very likely
also breaks in the main document. Should we only be allowed to specify
markups in Scheme macro syntax in future?
--
David Kastrup
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
