Fully implement ERB-like syntax (eRuby)

[e2b]

See ERB in the Ruby documentation:

ERB recognizes certain tags in the provided template and converts them based on the rules below:

<% Ruby code -- inline with output %>
<%= Ruby expression -- replace with result %>
<%# comment -- ignored -- useful in testing %>
% a line of Ruby code -- treated as <% line %> (optional -- see ERB.new)
%% replaced with % if first thing on a line and % processing is used
<%% or %%> -- replace with <% or %> respectively

This also features some escaping for ERB tags.

The trim_mode parameter is interesting, too:

If trim_mode is passed a String containing one or more of the following modifiers, ERB will adjust its code generation as listed:

%  enables Ruby code processing for lines beginning with %
<> omit newline for lines starting with <% and ending in %>
>  omit newline for lines ending in %>

[ollym]

I like all of this 👍

[e2b]

Is there anything missing? I've also found out using -%> (note the added minus sign) as end tag would omit a following newline while the old use of <%- and -%> (don't insert spaces before and after the output) seems deprecated. In the current source it's an option for the trim_mode:

#     -  omit blank lines ending in -%>

Should the syntax require a whitespace after/before the start/end tag? E.g. <%= foo %> will work, while <%=foo%> will not be recognized? Do you know how this is implemented in Ruby?

[ollym]

I've never used -%> in ERB templates. Seems pointless

[e2b]

I might still implement the minus option since it shouldn't be a big deal and it's deactivated by default (as long as not specified in trim_mode).

Should trim_mode be a new property within the options object or within the options.tags sub-object?

parrot.render(input, {
  trim_mode: undefined, // default
  ...
});

parrot.render(input, {
  tags: {
    trim_mode: undefined, // default
    ...
  }
});

The first one has less nesting and might be better if the tags aren't changed often (or custom tag support is dropped / unofficial in the future). The second one is obviously better categorized.