Alternative TeX-friendly delimiters

[vojtechkral]

Hi,
I am looking to using handlebars-rust in my project.
So far I've been using Tera, however, Tera has no dynamic dispatch mechanism, which I'm soon going to need as the structure of the input data gets richer. And handlerbars has the inline partials facility which looks like exactly what I need.

However I also need to generate LaTeX (as well as HTML) and using templates with {{-based delimiters, like handlebars, Tera etc. is very difficult in LaTeX. It's not impossible but it leads to a lot of weird bugs and hard-to-read template code. You can see my comments in the LaTeX template file - they are Tera-specific, but the situation with handlebars would be similar.

I've been exploring ways to add alternative delimiter support in handlerbars but this proved very difficult (as far as I can see). Pest has no way to express variations at build time (eg. no file inclusion etc.) and also even if you manage to define an alternative parser (this can be done with dirty build.rs code), switching between the two is difficult as all of the types (mainly the Rule enum) is completely different even though the content is the same.

So far, as a simple solution, I just forked handlerbars and edited the grammar to use <<-style delimiters, which should be just fine in LaTeX.

However I was wondering if maybe you had some advice how, if at all, this could be eventually upstreamed.

Also pinging the pest guys for advice @dragostis @CAD97

What do you think?
Thanks!

[sunng87]

If feature flag is allowed in pest grammar, it is possible (and also relatively elegant) to use feature flag to control the delimiter.

I'm not going to add runtime switch support because it means to create separated rules which will make this library a little bit bloated.

[sunng87]

@vojtechkral how about adding a preprocessor API to transform any template string into another. For your case, you can write your template with <</>> but use the preprocessing feature to transform them into standard handlebars delimiters.

[vojtechkral]

@sunng87 That sounds like a very neat idea indeed.

Do you think a TeX-friendly preprocessor function could be part of the library as well, or just the preprocessor API? (I'm asking to know how to scope a possible PR.)

[sunng87]

I think it's just preprocessor API to be included in the library. The TeX-friendly transform function should stay in your application for now. It will be flexible for you to make changes in the transformation.

[vojtechkral]

Okay, makes sense...

[vojtechkral]

@sunng87 Ah, I see you started implementing this as well.

Hold your horses please! I'm having second thoughts.

I tried implementing and using this and it turns out the actual preprocess function implementing alternative delimiters would need to be quite complex. Mostly because of correct escaping. It would need to implement detection of escaping of the new delimiters as well as escape the regular ones, and it would need to detect raw blocks as well, if done correctly.

I'm not 100% sure yet, but it seems to me right now maintaining a TeX-friendly fork might actually be easier for me...

[sunng87]

@vojtechkral I see. An alternative idea is to have a macro system similar to #DEFINE in C, where you can define the delimiter on the header of your template file. We can use it as a declarative api interface to control the behaviour of the parser. But it needs some design.

I will hold this for future ideas and possible scenarios.

[vojtechkral]

@sunng87 I agree. Sorry for causing you trouble, I only realized the complexity of the preprocess function pretty late...

[Roger-luo]

Hi @sunng87 I recently ran into this when trying to make a BibTeX template. Is there a way to do a contextual switch on the delimiter? The other use case is HTML or Markdown template with math equations. e.g a special helper function that uses a different delimiter inside it.

dasd klmdlkas daslkmdas

{{#angle}}
$$
\mathbf{<<name>>} = \frac{1}{<<bottom>>}
$$
{{/angle}}

I'm not sure if this is possible tho, but I assume if we let this helper function call a separate parser built with `<<>>`` grammar, this should work and give the same syntax tree?