From: matt Date: 2007-01-01T03:55:36+09:00 Subject: Re: ERb Request 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? Should not process the ERB Comment and the generated HTML would be > > > > 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