Idea: Preprocessor

[buschtoens]

As proposed here by @triccardi-systran, a preprocessor which runs through the code could solve many of our problems and could even lead to a performance increase (only lexing and parsing once).

For example, I would expect block and mixin definitions to be globally accessible, no matter when and where they were made.
A bit like JavaScript's function name() {} statement, but better.

The preprocessor should:

• resolve all includes (as in copy this in here)
• resolve all extends (as in concatenating the files)
• maybe find all block definitions in all files and save them globally
• maybe find all mixin definitions in all files and save them globally

[thomas-riccardi]

I just said the include should behave like a plain old replace by the file content.
I have no idea if a preprocessor is a good choice for the implementation.

The blocks and mixin scopes issues will also be resolved, at least for includes (there is still the case of extension), no need to do a first pass to find all blocks & mixin definitions. It could even be an issue with nested block definitions & other yields points.

[buschtoens]

@triccardi-systran I took your idea a step further, I've gotta admit that. But I wanted to credit you. 😃

The first pass scan for block & mixin defintions could free us from having to keep a certain order and could help with nested blocks.

append my-block
  p 2

block my-block
  p 1

[thomas-riccardi]

append before block already works, see layout.append.before-block.jade from my PR #1264.

[buschtoens]

Probably because it is defined by the layout (extends ../fixtures/block-in-block/layout).

In flat files without layouts, scanning a file or adding some kind of precedence for tokens would be neccessary. We can't test it yet as blocks in flat files are pretty buggy, as we already know. :D

[ForbesLindesay]

This goes counter to what a lot of people might expect.