On Fri, Nov 9, 2012 at 10:31 PM, David Kastrup <d...@gnu.org> wrote: > Janek Warchoł <janek.lilyp...@gmail.com> writes: >> Well, i don't quite understand why >> >> manualBeam = >> #(define-music-function >> (parser location beg-end) >> (pair?) >> #{ >> \once \override Beam #'positions = #beg-end >> #}) >> >> works then. > > Here #' is inside of LilyPond code, not inside of Scheme code. # > switches from LilyPond to Scheme, #{ from Scheme to LilyPond. # in > LilyPond is followed by _one_ Scheme expression, like 'positions or like > beg-end.
ah, ok. >> But nevermind, you don't have to explain this. I'd just want to say >> that from a user's perspective it's very frustrating that i cannot >> simply copy-and-paste some valid lilypond code into #{ #} > > You did not copy and paste valid LilyPond code into #{ #}. You replaced > a constant in a constant list by a symbol. That was not valid outside > of #{ #}, and it did not became valid inside of it. Hmm. Indeed. Too bad that to make the code valid one has to make it significantly different. >>> or quasi-quoting (backtick at the start, evaluated stuff with , before >>> it), like >>> #`((alignment-distances . ,distances)) >>> I am not entirely sure that . , is accepted, but if it isn't, >>> #`((alignment-distances ,@distances)) >>> should do the trick instead (,@ is the list splicing operator, basically >>> stripping one level of parens when inserting). >> >> looks like black magic to me. > > ' and ` are explained in pretty much every Lisp or Scheme manual or > introduction. Quoting stops Scheme from _evaluating_ an expression, and > a variable name that is not evaluated is just a symbol without any > connection to a value. Only when evaluated (so outside of quoting) is > the variable and value corresponding to a symbol looked up. I get the idea of quoting, but all these special characters with special meanings make me dizzy. Hmm. >> and have it work, especially when some similar code works without any >> problems. I hope that you know how to improve this situation >> somewhere in the future. > > Absolutely nothing I can do here. The Scheme interpreter and Scheme > syntax is a given. [...] On Fri, Nov 9, 2012 at 10:47 PM, David Kastrup <d...@gnu.org> wrote: > Actually, if you were using 2.17.6, you could just write > > staffdist = > #(define-music-function (parser location distances) > (list?) > #{ > \overrideProperty > Score.NonMusicalPaperColumn. > line-break-system-details.alignment-distances > #distances > #}) Now, that's *precisely* what i call "improving the situation"! I like this! :-) It may be surprising to you that i didn't try it. Here's why: i *did* try running convert-ly on that source file (i wasn't sure whether i'd get everything right), and it changed \overrideProperty #"Score.NonMusicalPaperColumn" #'line-break-system-details #'((alignment-distances . (30))) into \overrideProperty Score.NonMusicalPaperColumn.line-break-system-details #'((alignment-distances . (30))) i was surprised to see #'((alignment-distances . (30))), (with hash) but i didn't have time to investigate. So, maybe it's a defect in convert-ly? Anyway, your work is really cool! On Fri, Nov 9, 2012 at 10:52 PM, David Kastrup <d...@gnu.org> wrote: > Oh, and I'd use number-list? instead of just list? as a predicate. The > more generic your predicate is, the stranger the results for bad uses of > the function will become. If LilyPond sees that some predicate is > wrong, it pulls the plug on the whole function call and substitutes a > dummy value instead. Usually much more straightforward than if a value > gets accepted and problems occur afterwards. Good point, thanks for the advice :-) best, Janek _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user