Support using custom delimiters

[NikolaLohinski]

Hi ! First of all thanks for this awesome lib !

Do you have any plans on implementing a way to provide custom delimiters ? Either at compile time or at runtime.

This feature does not exist in Tera, and Askama’s approach makes it impossi ble to have runtime provided templates. I am writing a CLI to parse and render jinja2 templates using [[ … ]], [% … %] and [# … #] to avoid conflicting with other templating languages used in the files I am processing.

Thanks in advance !

[NikolaLohinski]

Hi @mitsuhiko . Thanks for taking interest in my request. Any news on this feature ?

[mitsuhiko]

@NikolaLohinski i looked into it recently again and it's quite a pain to implement and I wasn't sure if this feature is really that useful since editors also won't be able to handle custom Jinja delimiters. I just added raw tags, could they be helpful instead? (#69).

[NikolaLohinski]

Hi @mitsuhiko thanks for answering.

Regarding the raw tag : it would not help me because it would require me to escape every piece of conflicting delimiter every time I encounter them and there is lot.

Regarding editors : I don't understand how this is relevant to the feature itself. For sure most editors won't be able to parse jinja files with other delimiters but usually (at least for me), you want the file to be highlighted with the editor config for the underlying language, not for jinja itself. Should you have to template Python files (for whatever weird reason), you'd want the editor to show Python, not plain text with Jinja. My personal use case is to template HCL files.

Finally, if you consider it hurtful to implement, I can definitely look into it and take a shot at it if you would be so kind to accept a PR, and ideally give some thoughts on how you'd envision it.

[mitsuhiko]

I would be open to a PR if it does not pull in a new dependency. There are however definitely some API limitations right now that would have to be worked with. For one a new Settings object or similar could be added that's passed between the environment, template and the meta API and the lexer and other internals.

The tricky bit will be that using memstr internally will no longer work. For efficiently parsing arbitrary delimiters one would probably want to use something like aho-corasick except i don't want to add a dependency. If aho-corasick turns out useful, it could be added as an optional feature with the extra dependency.