Re: parser variables persist beyond { } scope

[Han-Wen Nienhuys]

On Fri, Jul 31, 2009 at 3:10 PM, Mark Polesky<address@hidden> wrote:
>
> Han-Wen Nienhuys wrote:
>> No.  In the specific case, I'd recommend making another music
>> function that takes an argument, so you can pass the 15/16
>> explicitly, without mucking with variables.
>
> So it sounds like you believe that one way or another, the burden
> should be on the user. Then do you think we should add a warning
> in the docs, something like this?
>
> "When the value of such a variable is changed in a .ly file, the
> change is global, and unless explicitly reverted, the new value
> will persist to the end of the file, affecting subsequent \score
> blocks as well as external files added with the \include command.
> This can lead to unintended consequences (if a variable is not
> explicitly reverted). Especially in complex typesetting projects,
> these types of errors can be difficult to track down."

I think in general the manual should not encourage users to define or
set variables using Scheme, exactly because the scoping semantics are
confusing. If the manual shows tricks that require this,  the
appropriate parts of Lily should be revised so it offers a less hacky
solution.

> I suppose we could also explain (in the docs) how to devise (in
> general) a custom music-function with the extra argument as you
> described, but this is a little trickier than simply pointing
> users to NR 6.1.3 "Paired substitution functions". Rewriting the
> music-function involves not only finding the location of its
> definition in the distribution files, but also manipulating the
> scheme code -- far more advanced than explicitly reverting the
> value, but much safer.
>
> What do you think?

You are misunderstanding me.  I think someone should go into the
lilypond source and create the function I suggested in the earlier
message.




-- 
Han-Wen Nienhuys - address@hidden - http://www.xs4all.nl/~hanwen