[feature] include should preserve indention

If someone does

<p>
  <%- include('other.ejs') %>
</p>

and other.ejs is

<div>
  <b>HELLO</b>
</div>

Then it should look like

<p>
  <div>
    <b>HELLO</b>
  </div>
</p>

Instead of

<p>
  <div>
  <b>HELLO</b>
</div>
</p>

[RyanZim]

BTW, you could also write your own function, like this:

<%
function indent(text, depth) {
  var output='';
  text.split("\n").foreach(function(line, num){
    // To avoid indenting the first line
    if(num>0){
      for(var i=0;i<depth;i++){
        line=line+' ';
      }
    }
    output+=line;
  });
}
-%>

Then you could do something like <%- indent(include('filename'), 4) %> if you wanted the include to be indented 4 spaces.

[TimothyGu]

@SBoudrias said:

FWIW, the reason was keeping compatibility with underscore templates.

Hmm. https://github.com/mde/ejs/issues/55#issuecomment-72275752.

Also, I don’t agree ejs doesn’t care about indentation (also for performance reason is total bollocks come on). Right now you have a ton of whitespace and indentation related features like whitespace trim or the slurp mode.

Just wanted to apologize for my tone in my last comment. I just realized that EJS right now was very different from the EJS I worked on a year ago.

A year ago, I was optimizing EJS as if it was a finished product, i.e. literally to the last inch, including replace costly .replace() calls with less costly ones and with even less ones. At the end, the template performance was on par with the fastest template engines out there, but the compilation performance still not so.

I approached this issue as if EJS still cared about compilation performance, but seems like we don’t any more. More specifically, features like <%_ _%> came along that basically added to the already slow compilation process with a bunch of unconditional .replace calls.

So again, I apologize. EJS has become something I didn’t think it was, and that anachronism in my head led to my comment.

On a more technical side, yes, those features might be doable, but will be hard to implement nevertheless. If dynamic inclusion is used, then a run-time solution like the one posed by @RyanZim would be much easier to use.