[email protected] writes:
Use David's wording for EM with some tweaks.
Re \displayMarkup \displayScheme:
Markup needs some special-casing as we have our own home-brew
customisable/extensible interpreter in there for interpreting \markup
arguments. The markup interpreter sometimes does some surprising
things
under the bonnet - like implicitly wrapping markup commands in #:line.
Would \displayScheme make debugging markups easier or more difficult?
Uh, nobody suggested changing its internals (except for letting it
accept more arguments). It uses display-scheme-music either way.
Should we have a \display <class> <expression> or \dump <class>
<expression> API to part-interpret a LilyPond expression to
scheme-primitives, display these to the console and/or file and
*never*
affect the output document? We now have \displayMusic,
\displayLilyMusic, \displayMarkup (and potentially \displayScheme), so
perhaps we need a one-stop shop function to interpret
Music/Markup/Scheme? E.g. \dump 'Music {c'4 e f g},
\dump 'Markup {\italic { "Hello " \bold {"Pond!"}}},
\dump 'Scheme #(reverse (list "Pond!" "the " "from " "Hello ")
These are good ideas but maybe stuff for another issue, given that
Mark's original fix was to clarify obtuse wording in the EM.
I think you are confused. We need separate \display*Music commands
because of having type coercion for its argument and being a music
expression, not because it would format things differently.
This requirement is not there for markups. LilyPond's display-*-music
commands accept any Scheme expression; they just format those internal
to LilyPond in a friendlier manner.
https://codereview.appspot.com/12732043/
_______________________________________________
lilypond-devel mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
