Lex Lucee's backtick template block

[ghedwards]

Closes #48.

name = "World";

Hello #name#

``` ```

The backtick had no lexer rule, so the fences vanished and the HTML between them was parsed as cfscript.

A lexer mode, built like the string modes

OPEN_TEMPLATE pushes InTemplate, CLOSE_TEMPLATE pops, and # pushes HashMode + DefaultMode — the same machinery InDoubleQuotes already uses, so interpolation works inside a template block exactly as it does inside a quoted string.

The visitor is the part that mattered

Grammar alone got a clean parse. It was also completely wrong, and silently:

name = 'World';
name;              <- markup gone, the interpolation leaked out as a bare statement

That's the trap CLAUDE.md describes, which is why the check here is decompiled output rather than the error count.

CFTemplateBlockStatement keeps the body as its source text and writes it back unchanged — it's markup, not cfscript, so modelling it would be inventing structure the parser can't validate. What a consumer actually needs is the interpolations, and those are parsed:

CFTemplateBlockStatement
  content=[\n<h1>Hello #name#</h1>\n<p>You are #user.age# years old</p>\n]
  interpolation: name
  interpolation: user.age

Both reachable via getExpressions() and decomposeExpression(), so a variable used only inside a block still reads as a use — the thing a linter would otherwise get wrong.

Verification

• 313 cfparser tests, ./gradlew build
• Differential harness 8 → 7, nothing newly broken
• CFLint 675 against a clean build
• Fixture fails with cfml.parsing/src/main stashed

Scope

Lucee-specific, same bucket as the extensions adopted in #34. The issue called it low priority — one corpus case, rare in real code — and that's still true; it's here because the remaining list was short enough to finish.

---

Generated by Claude Code