Allow Completely Custom Delimiters about ejs

[TimothyGu]

It's by design by @mde. No idea though on why he changed it.

[joshdickson]

Yeah I'd love an explanation @mde. It's confusing if you're using multiple tempting systems server-side. Nicer to just have completely alternate syntax. At quick look I don't see a technical reason why this was removed?

[mde]

The implementation of delimiters in the old version was one of the two non-standard features (along with filters) that I opted not to port over. There are multiple other (older) implementations of EJS which all implement delimiter customization the same way. AFAIK all the other similar templating engines (ERB, PHP, ASP et al) implement it the way we do now.

The old API for this also required a much more special-case implementation, because it wasn't simple replacement of single character across the entire range of available tags -- note that there are multiple open tags as well as closing tags. IIRC the old implementation didn't handle these. The only benefit I can think of of the old API was making EJS look like Mustache templates, which doesn't seem like a huge practical value given the amount of work that would be required to port and maintain the feature.

Hope that answers your question.

[joshdickson]

For the case where you're using multiple templating engines, I consider it pretty important. I don't want an EJS template to appear, at first glance, to look anything like another template that we're using, and the ability to do this is why EJS ended up in our code base in the first place. As EJS is going to be server side and it's likely you're using something else client side (Mustache, Underscore, etc) that also might be periodically called on server-side, I think it should have remained as a feature as it had always been in the library.

That said I understand this is a specialized use case. It sounds like you don't want to entertain adding this back, which is disappointing.

[mde]

Sorry for the inconvenience here. I understand why you might want it, but it would add a significant amount of complexity for a very minor use-case. As far as it "always being in the library," The v1 of the NPM lib for EJS is only one of at least four implementations of EJS that I know of going back to the early 2000s, and none of them ever had anything like this AFAIK. The v1 code also had a non-standard "filters" feature that didn't make the cut. One of my goals with EJS was to bring it more in line with all the other implementations (and other similar templating languages like ERB, PHP, et al), and remove non-standard features, and unfortunately this is one of the casualties. I'm going to go ahead and close this issue.

[timschoch]

If you want to create asp pages within a yeoman generator this would be very helpfull too. Currently I have to pass two variables aspOpen and aspClose and echo them out <%= aspOpen %>do something<%= aspClose %> - not soooo nice.