Valentin, I couldn't comment inline on the scm file, because it gave me a server error when I tried.
Here's the comments I put in on your new macro: I'm concerned about redefining a public function so that the arguments mean totally different things. This will totally break any existing scores that use def-grace-function. At the very least it needs a convert-ly rule. I'm concerned about code that requires functions to have a particular name in order to work properly. While we *can* do it with Scheme, I don't think it's a good idea. With the old code I have complete control over what I want to do to start and stop grace music. WIth this code my start and stop functions have to have a particular name or they won't work. I appreciate your work. I think this is an important change to LilyPond, but I the architecture I propose in music-functions-init.ly is better. THanks, Carl http://codereview.appspot.com/3169041/diff/3001/ly/music-functions-init.ly File ly/music-functions-init.ly (right): http://codereview.appspot.com/3169041/diff/3001/ly/music-functions-init.ly#newcode35 ly/music-functions-init.ly:35: #(def-grace-function AcciaccaturaMusic BeamedAcciaccaturaMusic Since the problem is only with acciaccatura, why not just change the definition of acciaccatura so it's a music function with one ly:music? argument that evaluates the music argument to see if it's a sequential music with more than one element. If so, then use a def-grace-function for StartBeamedAcciaccatura, StopAcciaccatura, and then spit out the music? This would keep the current infrastructure intact and require no conver-ly rules, and wouldn't affect anything that is currently working. http://codereview.appspot.com/3169041/ _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel