Simon Albrecht <simon.albre...@mail.de> writes: > To just give my personal opinion, it would be brilliant to have > > (define (foo arg) <body>) > (define-music-function (foo arg) (arg-type?) <body>) > [&c.] > (define-markup-command (foo arg) (arg-type?) <body>)
I don't share your sentiments here. Now define-music-function is arguably misnamed as it is more of a music-lambda rather than something fitting into the "define" category. But between define-markup-command and define-music-function, the latter has by far the cleanest semantics even if its name does not fit them. I'm more interested in merging all define-*-function commands eventually, making them decide their syntactical function based on their return value type. However, that's non-trivial mainly because of \displayMusic c'4 \displayMusic -. Here LilyPond does not know that the second expression is (as a post-event) to be a part of the c'4 before it has evaluated it. So the \displayMusic expressions would need to be evaluated right from left, displaying first "-." and then "c'4-.". But before the right expression is evaluated, its type is unknown, so \displayMusic c'4 \displayMusic d'4 would also need to be evaluated right to left, displaying first "d'4" and then "c'4". Which is clearly less than desirable. So something has to give. > Not only would it be more consistent on the surface, it would also > have less potential for confusion upon learning. Frankly, I rather doubt those are the showstoppers. Markup commands are pretty much a pest. Joining them with markup list commands would be a good first step for cleaning up that can of worms. Music functions are rather easy to work with in comparison, even if the name define-music-function renders the "Extending LilyPond" guide ineligible for the Nobel Prize in Literature. -- David Kastrup _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
