bug-lilypond
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: \\bookOutputName not working if a \\paper block uses a previously de


From: James
Subject: Re: \\bookOutputName not working if a \\paper block uses a previously defined variable
Date: Mon, 26 Mar 2012 18:23:39 +0100

Hello,

On 26 March 2012 15:14, Eluze <address@hidden> wrote:
>
>
> Am 26.03.2012 02:44, schrieb David Kastrup:
>
>> Eluze<address@hidden>  writes:
>>
>>> Am 25.03.2012 23:50, schrieb David Kastrup:
>>>>
>>>> Eluze<address@hidden>   writes:
>>>>
>>>>> Am 25.03.2012 19:35, schrieb David Kastrup:
>>>>>
>>>>>
>>>>>
>>>>> Personally, I think it would make more sense if people just placed
>>>>> assignments to output-filename and output-suffix inside of the book's
>>>>> paper block.  That's straightforward to understand and does not require
>>>>> keeping magical ordering relations in mind.  \bookOutputName is more
>>>>> like a compatibility API.  A courtesy to keep around, but not as
>>>>> straightforward in its implications.
>>>>>
>>>>>
>>>>> this works:
>>>>>
>>>>> bigMargin = \paper { top-margin = 10 \cm }
>>>>> \book {
>>>>>    \paper {
>>>>>      \bigMargin
>>>>>      #(define output-filename "output-filename")
>>>>>    }
>>>>>    \relative {c d e f}
>>>>> }
>>>>
>>>> Ugh.  Why don't you write
>>>> \paper {
>>>>    \bigMargin
>>>>    output-filename = "output-filename"
>>>> }
>>>
>>> I found this weird expression in the docs - other forms are not
>>> mentioned.
>>
>> Ugh.  Sounds worth fixing.
>>
>>> I will gladly apply the simple form now!
>>>>>
>>>>> this not (because of the order):
>>>>>
>>>>> \book {
>>>>>    \paper {
>>>>>      #(define output-suffix "output-filename")
>>>>>      \bigMargin
>>>>>    }
>>>>>    \relative {c d e f}
>>>>> }
>>>>
>>>> Hardly surprising now, is it, if you write it as _assignment_ rather
>>>> than as some weird Scheme block?
>>>
>>> putting the assignment before \bigMargin still produces an error and
>>> the output returns to default.
>>
>> Exactly.  A predefined output definition has (if at all) to come first
>> in any new output definition.  The same with context definitions.
>>
>> It is a bit weird how they find their target if not given.
>>
>> \layout { \context { \Voice ... } }
>>
>> manages to change the variable Voice in \layout's module.  The reason is
>> not that this syntax would specify which variable to change: indeed,
>> \Voice just _fetches_ a copy of the variable Voice.  But this variable
>> is a context definition containing a name = "Voice" definition, and
>> that's enough for this purpose.  If you write
>>
>> \layout { silly = \Voice
>>           \context { \silly ... } }
>>
>> then the changes end up in the definition of Voice, not in the
>> definition of silly, exactly because of that name = "Voice" def.  Or
>> with
>>
>> \layout { \context { \Voice name="TabVoice" ... } }
>>
>> you redefine TabVoice starting from a copy of Voice (at least I think
>> so).
>>
>> For output definitions, if you use them "naked" like
>>
>> xxx = \paper { ... }
>> \book { \xxx }
>>
>> then book knows to treat this like a paper because xxx has, in its
>> module, a variable is-paper set to #t.
>
>
> thanks - now I understand (at least a little better)!
>
> I don't think this should be broadly explained in the manual (certainly not
> under the topic /Output file names /or /Multiple output files from one input
> file/) - there must be better places.
>
> I attach my version of chapter NR 3.1.3 + 4 (in simple html). It is shorter
> and I think the needed information is there.
>
> I have included a /note /about the order but as I said above there might be
> better places for that (where the \paper block is discussed, maybe).
>
> with no objection I will open a new Doc enhancement request (also asking to
> remove these weird definitions).

Sure, go for it.

Could you though de-html-ize it unless you are going to do the patch.
I'd personally rather work with plain text instruction.

Thanks

James



reply via email to

[Prev in Thread] Current Thread [Next in Thread]