This looks fine for committing to me. There are several obvious
followup issues/commits making a lot of sense afterwards, however.
One is the obvious complement with \displayLilyScheme which makes sense
to do before the others, namely providing a notice in
Documentation/changes.itely and making
David Kastrup wrote:
I vote to go ahead with adding \displayMarkup.
Huh? Can you name a _single_ advantage that is gained
by having \displayMarkup (which is only different from
\displayScheme by refusing to accept a number of
arguments) instead of \displayScheme?
Of course not. I meant
LGTM, but add suggested clarification to EM text.
Ian
https://codereview.appspot.com/12732043/diff/7001/Documentation/extending/programming-interface.itely
File Documentation/extending/programming-interface.itely (right):
https://codereview.appspot.com/12732043/diff/7001/Documentation/extending/programming-interface.itely
File Documentation/extending/programming-interface.itely (right):
https://codereview.appspot.com/12732043/diff/7001/Documentation/extending/programming-interface.itely#newcode650
https://codereview.appspot.com/12732043/diff/7001/Documentation/extending/programming-interface.itely
File Documentation/extending/programming-interface.itely (right):
https://codereview.appspot.com/12732043/diff/7001/Documentation/extending/programming-interface.itely#newcode277
On 2013/08/15 10:36:06, dak wrote:
Also, the only thing that makes this \displayMarkup rather than
\displayScheme is the restriction of the argument type to markup?.
Perhaps
it would make sense to call the whole function \displayScheme instead
and allow
arguments of type scheme? here?
+1
On 2013/08/15 11:24:15, thomasmorley651 wrote:
On 2013/08/15 10:36:06, dak wrote:
Also, the only thing that makes this \displayMarkup rather than
\displayScheme is the restriction of the argument type to
markup?.
Perhaps
it would make sense to call the whole function \displayScheme
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
ianhuli...@gmail.com 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
David Kastrup wrote:
Any chance to join them completely?
Not yet. It's a long-term goal. And of course, there are a
few things that are not easily reconciled: compare
\void\displayScheme -5
with
\void\displayMusic -5
Well, I played around with this, and David's example is
pretty
On 2013/08/16 02:38:49, Mark Polesky wrote:
David Kastrup wrote:
Any chance to join them completely?
Not yet. It's a long-term goal. And of course, there are a
few things that are not easily reconciled: compare
\void\displayScheme -5
with
\void\displayMusic -5
Well, I played around
LGTM
https://codereview.appspot.com/12732043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
This disturbed me to, though, not to a point that I started to work on
it my own. ;)
One thought:
https://codereview.appspot.com/12732043/diff/1/ly/music-functions-init.ly
File ly/music-functions-init.ly (right):
Reviewers: ,
Message:
Hi all, here's a new patch.
- Mark
Description:
Issue 3491: http://code.google.com/p/lilypond/issues/detail?id=3491
Please review this at https://codereview.appspot.com/12732043/
Affected files:
M Documentation/extending/programming-interface.itely
M
14 matches
Mail list logo
