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
