I have a question about document structure, because I want to structure a series of products correctly and I do not know if I understand everything in the manual about it well enough. Must I understand that "\startlocalenvironment[abc]" within an environment file means that this codeblock is used only for typesetting product/component abc and excluded automatically when another product/component is typeset? Or is it just a declaration analogous to "\startenvironment file setups \stopenvironment"? But then I don't understand why the manual does not tells me "\startlocalenvironment[abc] file setups \stoplocalenvironment" as it does for \startenvironment The macro "\localenvironment name" gives me some headaches. I might guess usage in a master setup file as: \localenvironment abc % load environment file abc.tex if typesetting product/component abc \localenvironment xyz % load environment file xyz.tex if typesetting product/component xyz How does this relate to the above question about setup-file structure? Hans van der Meer
Hans van der Meer wrote:
Must I understand that "\startlocalenvironment[abc]" within an environment file means that this codeblock is used only for typesetting product/component abc and excluded automatically when another product/component is typeset?
I believe so.
How does this relate to the above question about setup-file structure?
\localenvironment is sort of an alias of \environment. Differences: there is a but less bookkeeping done, and the file is loaded only once in a run, never repeatedly (so that the command can safely be used in a number of components). The files' name (== the argument) is unimportant. Cheers, Taco
On Jul 21, 2006, at 14:58, Taco Hoekwater wrote:
Hans van der Meer wrote:
Must I understand that "\startlocalenvironment[abc]" within an environment file means that this codeblock is used only for typesetting product/component abc and excluded automatically when another product/component is typeset?
I believe so.
How does this relate to the above question about setup-file structure?
\localenvironment is sort of an alias of \environment.
Differences: there is a but less bookkeeping done, and the file is loaded only once in a run, never repeatedly (so that the command can safely be used in a number of components). The files' name (== the argument) is unimportant.
Sorry, but I think I do not yet understand and I do not get it right. Next is in a nutshell my setup of the environments, the relevant projects are syllabus-s and syllabus-p % calls up the product, file syllabus-s.tex \startproduct syllabus-s \project onderwijs \environment syllabus-setup ... \stopproduct % common initializations, file syllabus-setup.tex \startenvironment syllabus-setup \writestring{LOADED ENVIRONMENT SYLLABUS-SETUP}\writeline \startlocalenvironment[syllabus-s] \localenvironment syllabus-s-setup \stoplocalenvironment \startlocalenvironment[syllabus-p] \localenvironment syllabus-p-setup \stoplocalenvironment % setups local to p-version, file syllabus-p-setup.tex \startlocalenvironment[syllabus-p-setup] \writestring{LOADED ENVIRONMENT SYLLABUS-P-SETUP}\writeline \stoplocalenvironment % setups local to s-version, file syllabus-s-setup.tex \startlocalenvironment[syllabus-s-setup] \writestring{LOADED ENVIRONMENT SYLLABUS-S-SETUP}\writeline \stoplocalenvironment Running from product syllabus-s.tex I get this in the log: systems : begin file syllabus-setup at line 10 (./syllabus-setup.tex LOADED ENVIRONMENT SYLLABUS-SETUP systems : begin file syllabus-s-setup at line 6 (./syllabus-s-setup.tex LOADED ENVIRONMENT SYLLABUS-S-SETUP ) systems : end file syllabus-s-setup at line 6 systems : begin file syllabus-p-setup at line 10 (./syllabus-p-setup.tex LOADED ENVIRONMENT SYLLABUS-P-SETUP ) systems : end file syllabus-p-setup at line 10 And this shows that running the product syllabus-s still loads both localenvironments and goes inside both \startlocalenvironments! What I am doing wrong here? Hans van der Meer
Hans van der Meer wrote:
Sorry, but I think I do not yet understand and I do not get it right. Next is in a nutshell my setup of the environments, the relevant projects are syllabus-s and syllabus-p
My unsterstanding is that you do it like this: % syllabys-s.tex \project syllabus \localenvironment syllabus-local-setup \starttext \stoptext % syllabys-p.tex \project syllabus \localenvironment syllabus-local-setup \starttext \stoptext % syllabus.tex: \environment syllabus-setup % syllabus-setup.tex \writestring{global env settings} % syllabus-local-setup.tex \startlocalenvironment[syllabus-s] \writestring{this is only for the screen version} \stoplocalenvironment \startlocalenvironment[syllabus-p] \writestring{this is only for the print version} \stoplocalenvironment (Untested) Cheers, taco
On Jul 22, 2006, at 10:19, Taco Hoekwater wrote:
Hans van der Meer wrote:
Sorry, but I think I do not yet understand and I do not get it right. Next is in a nutshell my setup of the environments, the relevant projects are syllabus-s and syllabus-p
My unsterstanding is that you do it like this:
% syllabys-s.tex \project syllabus \localenvironment syllabus-local-setup \starttext \stoptext
% syllabys-p.tex \project syllabus \localenvironment syllabus-local-setup \starttext \stoptext
% syllabus.tex: \environment syllabus-setup
% syllabus-setup.tex \writestring{global env settings}
% syllabus-local-setup.tex \startlocalenvironment[syllabus-s] \writestring{this is only for the screen version} \stoplocalenvironment \startlocalenvironment[syllabus-p] \writestring{this is only for the print version} \stoplocalenvironment
(Untested)
No, I must be my fault, but even with the above help I cannot get it working. As far as I can figure out the value of \currentproduct seems NOT to guard entry to the body of \startlocalenvironment[syllabus-s]. Although the manual here explicitely mentions "component or product", I cannot see that happen. Also \localenvironment seems to accept any file for reading instead of rejecting everything except the current product/component. In the code of core-job.tex I read: % more or less replaced by modes \setvalue{\e!start\v!localenvironment}[#1]% .... Must I conclude from this that localenvironments are more or less passe? So that I can better avoid them and use modes (after \enablemode) as discriminating criterium? Hans van der Meer
Hi Hans-es, Hans van der Meer wrote:
No, I must be my fault, but even with the above help I cannot get it working. As far as I can figure out the value of \currentproduct seems NOT to guard entry to the body of \startlocalenvironment[syllabus-s].
This took a bit of digging, it appears to be a bug in core-job.tex. The definition of \setvalue{\e!start\v!localenvironment} ends with: {\grabuntil{\e!stop\v!localenvironment}\relax}} but that should be: {\grabuntil{\e!stop\v!localenvironment}\gobbleoneargument}}
Also \localenvironment seems to accept any file for reading instead of rejecting everything except the current product/component.
Yes, it only guards against loading the environment file twice. The name is irrelevant.
In the code of core-job.tex I read:
% more or less replaced by modes \setvalue{\e!start\v!localenvironment}[#1]% ....
Must I conclude from this that localenvironments are more or less passe? So that I can better avoid them and use modes (after \enablemode) as discriminating criterium?
There are probably system modes predefined for the products name etc. I'll leave the question to be answered by Hans. Taco
On Jul 22, 2006, at 14:19, Taco Hoekwater wrote:
Hans van der Meer wrote:
No, I must be my fault, but even with the above help I cannot get it working. As far as I can figure out the value of \currentproduct seems NOT to guard entry to the body of \startlocalenvironment[syllabus-s].
This took a bit of digging, it appears to be a bug in core-job.tex. The definition of \setvalue{\e!start\v!localenvironment} ends with:
{\grabuntil{\e!stop\v!localenvironment}\relax}}
but that should be:
{\grabuntil{\e!stop\v!localenvironment}\gobbleoneargument}}
This patch repairs it. Now \startlocalenvironment[syllabus-s] is properly entered when the argument matches the product. One more bug has been ironed out. But the fact that it took so long before it surfaced is telling, obviously not many people have used this mechanism since the manual came out! Thanks for acting so fast. Hans van der Meer
participants (2)
-
Hans van der Meer -
Taco Hoekwater