On Wed 24 Nov 2021 at 19:44:59 (+0100), Paolo Prete wrote: > > and then comment or comment out parts of the score that I don't need to > > render. So, for example, if I need to render only section 2, I would > > comment section 3 and section 1 but I have to comment the markup block > > separately as well: this is unwanted, because the markup belongs to section > > 1 context. Instead, it would be more appropriate to exclude automatically > > the markup block when section one is not included. > > Note that putting the sections into separate files, as you suggested, does > > not solve the problem: instead of commenting blocks of code, I would have > > to exclude both the file associated to the markup and the file associated > > to section 1, if I want to render section 2. > > Now, if I try to by-pass the problem with a \book context, I can embed the > > markup into section 1:
> I see what you mean (thanks for your further explanation) but it would not > work for what I want to achieve. I try to explain why. > My example is focused on _rendering_. With your procedure, I would > statically fix portions to be rendered separately, and each portion would > be a separate file. This is good when writing parts, or when writing > movements of a composition. But in my case, all the sections dynamically > vary because they represents what to be rendered. > This means that, for example, when a section takes too much time to be > rendered, I can decide to shrink it. Then, for example, I fix a problem, I > verify the problem has fixed (---> rendering) and then I enlarge it to its > original size ( == amount of rendered measures). This is what I do very > often (it saves much time!) and this is why I comment/comment out portions > of the score. >From the description above, it seems as if you're manually preprocessing your code by inserting %{ and %} strings at appropriate places for the compilation concerned. If you do this regularly, I would suggest that that's just what you do, copy your source through a simple filter to a temporary file and compile that. Directives such as: %%% PAOLO %%% +foo -bar could turn on/off copying the source at multiple points so that inclusions of related material occur when you run, say, filter foo baz Such a filter is very easy to construct because you have total control over what it sees and reacts to. And I think it would be less error-prone that fiddling with %{ %} strings. Feel free to ignore this method. Cheers, David.