can we also have shorthand for html encoding the output?
http://underscorejs.org/#template supports the following syntax

@Michael Offner: I think "not correct" is overstating things somewhat, as we're discussing shorthand syntax, and where we have

Wherein the current long-hand equiv would be:

or

We could also have a further shorthand of:

Where currently we'd have:

These are two distinct things, and I think you're conflating them somewhat. Or thinking I am. Fair enough if it's the latter: I guess I wasn't as clear as I could have been.

Coming from PHP, basically what Brad was asking for is the equiv to PHP's <?php syntax (NB: closing tag is optional in PHP now... something else to consider).

On the other hand, PHP also has short-hand for <?php echo someStringExpression ?>, which is simply <?= someStringExpression ?>. It was this sort of adjunct I was also suggesting, as it's complementary to Brad's suggestion.

That said, now that I think some more there's less merit for that in a CFML-oriented situation (be that CFML or .lucee), because CFML is still made of individual tags, whereas PHP moved away from that a decade or so(?) ago. There's less need for that in CFML, when one can simply use #someStringExpression# (presupposing, again, there's a <cfoutput> around it somewhere).

Update: TBH, from a view perspective, and thinking only of .lucee, I think tags should be done away with completely anyhow, in favour of a recognised templating implementation (Handlebars etc). So perhaps the short-hand echo equivalent would not be so appropriate anyhow. I'm still stuck thinking of seas of grim old <CFML tags>, which if I never see again would be too soon.

actually this is not correct:
-----------------------------------

will be equivalent to:

-----------------------------------

the ## only declares an expression and do not force lucee to write to the response stream.
take this example
<cfset x=#1+1#>
this does not force lucee to write to the response stream, it agin only declares that within is an expression, even this is unnecessary, this is a valid syntax.
Writing to the response stream is happening anyway, the ## only declare an expression

In fact the name of the tag <cfoutput> is wrong in my opionion, it should be something like <cfparse> or <cfparseHash>.
only <cfsetting cfoutputonly> give the tag cfoutput sense.

anyway, the ## are not about make the output or not, they are only about parse the expression within or not.
So the problem is that within the tag context everything is written to the response stream.

so in my opinion we need something similar to ## that tell lucee also to parse it but to supress the output
, because of that i'm more for something like:

i would like this syntax for 2 reasons:
1. t looks similar to ##, like a lightway version of it
2. easy to make on the keyboard

BTW i make dump a lot of times this way, because it is the fastest way to do it

@Imported User 30 in .lucee, one still uses # for delimiting an expression that's supposed to be evaluated in an otherwise ambiguous situation, yeah? That being the case, <# ... #> makes more sense to me than <: ... :>. Or am I not seeing some nuance of what yer saying?

[...] thinks some more [...]

Nah, OK I get it. It's implying its kinda a general shorthand tag, so instead of <:somespecifictag>...</:somespecifictag>, it's just <:...:>, ie a general tag-based code construct. Cool, and makes sense.

I think that's likely to be decided on a case-by-case basis. If an ER would be generally useful to CFML developers and still backward compatible with ACF/Railo (i.e., it would not break any existing working programs), then it's reasonable to consider adding it to the CFML dialect in Lucee.