I've introduced a new token for this "|-"

Yeah, we should avoid that. The old operator should be able to support it, right after parsing it, you can force to flush the whitespaces tokens coming and attach them.

but I'm not sure if |> has a special meaning in Scientific mode?

It's actually the pipe operator in scientific. We cannot change that for regular Scriban that was following Liquid syntax for that.

Yeah, we should avoid that. The old operator should be able to support it, right after parsing it, you can force to flush the whitespaces tokens coming and attach them.

Not sure if you had something else in mind but I solved this by simply looking ahead via the IsRemainderOfLineWhitespace method. There is one minor implication which is that the error message for an unterminated pipe now uses the position of the next non-whitespace token rather than the end of line (which seems sensible).

So the current syntax is:

"test"    |
       string.prepend "start"   |
       string.append   "end |
       string.upper  

but if you write

"test" |
string.prepend "start" |
}}

You get an error saying "expecting expression instead of '}}'" now instead of "expecting expression instead of <newline>" which actually seems clearer in any case.

Yeah, we should avoid that [introducing a new TokenType ...] right after parsing it, you can force to flush the whitespaces tokens coming and attach them

Possibly I have misunderstood you? DId you mean to try and handle this by looking ahead for whitespace tokens in ParserExpression when a VerticalBar is encountered? The reason to introduce a PipeOverLineBreak Token originally was to avoid breaking any code that assume a VerticalBar really was just a single-character token (as the name suggests).

Possibly I have misunderstood you? DId you mean to try and handle this by looking ahead for whitespace tokens in ParserExpression when a VerticalBar is encountered? The reason to introduce a PipeOverLineBreak Token originally was to avoid breaking any code that assume a VerticalBar really was just a single-character token (as the name suggests).

See my comment above. | should stay a single character. The handling of newlines is done at the parser level.

LGTM, thanks!

Thanks for pushing the last changes!

Thanks for pushing the last changes!

No problem - very much looking forward to using this feature :-)