Prefer double underscore "__" over double brackets "{{" for templates

[MarcusCemes]

Fantastic extension! I wanted something like this so bad!

I would like to suggest using the double underscore escape method even inside of templates. Handlebars are not compatible with a vast majority of file types. For example, they will completely break the Javascript/Typescript syntax.

In this example, VS Code will freak out with cryptic errors, the file is marked as containing errors, and will appear red in the sidebar recursively to the project folder. It's not possible to switch off VS Code's internal validation for particular folders without workarounds such as remapping file associations to something like text file for particular folders.

Blueprint files should be able to be valid language-linted files, but that's impossible with the current template literals.

Double underscore based literals (with no spaces!) would be highly compatible (and unique!) for HTML, Javascript, CSS, C++, Java as underscores are generally accepted in variable names. A simple config option could choose between "{{" and "__", and handlebars could be replaced with simple regex substitution (why not? handlebars wasn't designed to handle every file format anyway).

It would help solve issues with escaping, language-specific constraints and linting, conflicts with other handlebars: #58, #69, #56, #39

Examples for in-template substitution would be: __name__, __camelCaseName__, __snakeCaseName__, ... Or even better, prefix with bp: __bpName__.

[Andkoo]

Hey, check #69

[MarcusCemes]

@Andkoo It's a workaround for escaping handlebars.

My issue addresses a better delimiter token and variable naming scheme that doesn't break language servers due to illegal syntax, while also having the benefit of not conflicting with real handlebars or similar markup such as React's JSX props.

[reesemclean]

We'll never get a perfect delimiter that works well across all languages but I'm in agreement that the double underscores would be a better one... because this would be a breaking change I'm not sure the best way to make that happen. Maybe we could add a migration notice? I.e. the first time the user runs the extension we prompt the user that the format has changed and we try to update their templates for them (or let them update them themselves).

I think I am against making the delimiter a preference that the user selects in VSCode as that would reduce the ability to share templates. Maybe we could have some sort of optional Frontmatter in a file (that does not get copied over) that allows the template to define what the delimiter it uses so that the delimiter is at the file level. This could be a separate change.

As for handlebars -- that was really supposed to be an internal detail and could be swapped out at any point (as long as backwards compatibility remains).

If you want to try to tackle either of those I would be okay with them but keeping backwards compatibility (or an easy migration path) is very important as I never like to wake up and try to use a tool to find it no longer works for me just because I updated.