Inline comments below.

On Mon, 2007-01-01 at 03:05 +0900, Phrogz wrote:
> matt wrote:
> > Well what it looks like is a bit of preference, and it should stick with
> > ERb's '<%' tagging convention, so something like '<%*' and '*%>'
> >
> > It will absolutely need to have mandatory start and end tags that are
> > distinguishable from other tags, and be able to ignore all data and
> > information within these tags, sending nothing to the browser (or other
> > stream)
> 
> Here's a simple patch that does this:
> 
> [sliver:/usr/local/lib/ruby/1.8] gkistner$ diff -u erb.rb
> erb_with_block_comment.rb
> --- erb.rb      2006-12-31 10:53:06.000000000 -0700
> +++ erb_with_block_comment.rb   2006-12-31 10:54:01.000000000 -0700
> @@ -688,7 +688,7 @@
>      @safe_level = safe_level
>      compiler = ERB::Compiler.new(trim_mode)
>      set_eoutvar(compiler, eoutvar)
> -    @src = compiler.compile(str)
> +    @src = compiler.compile(str.gsub(/<%\*.+?\*%>/m,''))
>      @filename = nil
>    end
> 
> Probably this would be better implemented as part of the scanner for
> ERB, but this could be a base test for desired functionality around
> edge cases.
> 

I agree, the scanner is where it should be implemented in the end, but
this is a good start.

> > 1. nested block comments should be checked
> > <%* <%*  *%> *%>
> 
> What do you mean by 'checked'? Allowing nesting, or throw an error?
> The simple hack I provided above fails on nested comments.
> 
Checked in the sense of finding the occurrence, throw an error if found.

> Is this really important? As far as I know, C++, JavaScript and Ruby
> all disallow the nesting of their block comment style. Lua allowed it
> in 5.0, but as of 5.1 it requires that the author use unique block
> comment delimiters for each nested level.
> 
> It's certainly doable...but is the performance cost worth it?
> 
> > 2. N start tags and N-1 stop tags
> > <%* <%* *%>
> 
> I would say that, like other languages, this case should be treated
> fine. (You're asking ERB to ignore all things that look like ERB
> commands inside the block comment; shouldn't that include ignoring
> something that looks like a block comment start?

I was thinking this would be an error.  

What if:
<%* Comment 1  Other Stuff Not Commented <%* Comment 2 *%>

Was supposed to be:
<%* Comment 1 *%>  Other Stuff Not Commented <%* Comment 2 *%>

It could certainly be treated as a single block, with a warning in the
logs that the condition was caught and treated as a single block.  Or
this could be an environment option that is set on how the author wants
it treated.  I personally like things to error out, but I know others
don't. 

> 
> The hack I have above treats this as a single block comment.
> 
> > 3. M start tags and M+1 stop tags
> > <%* *%> *%>
> 
> The hack I have above treats this case as degenerate, leaving a lone
> *%> in the source and causing ERB to barf. This seems consistent with
> how many other languages handle block comments.

Yeah, similar to #2 above

What if:
<%* Comment 1 *%> Other Fine Code   Comment 2 *%>


Was supposed to be:
<%* Comment 1 *%> Other Fine Code  <%* Comment 2 *%>

This case I think doesn't have a choice but to throw an unrecoverable
error, but should be able to return the last comment tag line number and
position for quick reference.

> 
> 
> >   Erb Comment within HTML Comment
> >   <!-- <%*  *%> -->
> 
> This should emit an HTML comment with no content, correct?

<!-- HTML Comment 1 <%* ERB Comment  *%> HTML Comment 2 -->

Should not process the ERB Comment and the generated HTML would be 
<!-- HTML Comment 1 HTML Comment 2 -->

> 
> 
> >   Overlapping HTML/ERb comment
> >   <!-- <%*  --> *%>
> 
> This should emit broken HTML (an unpaired comment start), since ERB has
> no knowledge of SGML/HTML/XML.

Yeah, since the <%* tags won't process, it will find the first HTML tag
and no matching end.

> 
> 
> > By making a block comment for embedded Ruby, there would be a way to
> > section out large parts of code quickly, easily, and still maintain
> > continuity of work.
> 
> I'm a fan of this idea, just want to make it solid and make an attempt
> at a good implementation before asking for a patch on ruby-core.
> 

Great, I know nothing of the Ruby core, so I'll be of little help there
(for now), but I will always do my part to suggest improvements and
upgrades with as much help and detail as I can provide.



Matt