Re: Issue 3491: Add \displayMarkup command. (issue 12732043)

[dak]

address@hidden 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/