Add experimental CFML support

[ghedwards]

Add experimental CFML support

[Xophmeister]

I've left some suggestions in the comments, but as a wider point, I think it would be worth understanding just how "experimental" your contribution is. While we don't have any written policy about how thorough an experimental contribution should be, my gut feeling -- looking at just 22 lines of queries -- is that this is probably on the low side. If someone other than yourself were to try formatting an arbitrary CFML file with these rules, how much would break? Can you estimate how much of the CFML grammar (which I understand is a superset of HTML) is covered by your queries?

---

Besides this, I would also suggest removing the changes to the WASM binaries from this PR. That is, web-playground/public/scripts/*.wasm; including the WASM for CFML. This goes with a wider suggestion of removing all the WASM/playground related changes from this PR: The WASM/playground code is currently in maintenance and not actively worked on. Moreover, the CI is currently set up to not even build/deploy the playground from main.

We don't want to give the impression that the WASM/playground changes in this PR will work -- without them being tested -- nor create any future maintenance problem by virtue of the existence of untested code. (Outside of this PR, the Topiary Team should make this clear in our README, to avoid others unnecessary work.)

There are a few random changes to some other binaries -- besides the WASM blobs -- that should also be removed from this PR:

• web-playground/public/favicon-32x32.png
• website/images/topiary.png
• website/images/topiary_logo.png

Could you please clean these up?

[ghedwards]

Made changes, please review

[Xophmeister]

Thanks for making those changes 🙏

This is looking closer to what's needed and the CI looks like it's happy. However, we must address the "how experimental is this?" question.

Here, for example, we see a case where the formatted output is semantically different from the input (a literal whitespace is removed):

$ topiary fmt -lcfml <<CFML
> <div>Hello <b>world</b></div>
> CFML
<div>Hello<b>world</b></div>

I don't know CFML, so I cannot assess how complete your formatting queries are. However, if it's a superset of HTML, then this simple example will be far from the only problem. We don't want to give users the wrong impression of Topiary if it doesn't meet their expectations.

Perhaps, as a compromise, you can mention in the README -- where you've added CFML as an experimental language -- that it only covers basic cf* tags currently and doesn't format HTML. What do you think?

---

Additional changes:

• Please add a CFML link in the README (see comment, below).
• Please add an appropriate entry to the CHANGELOG.

[Xophmeister]

I don't think this should be here, but looking into it further, it looks like this Cargo.lock file is redundant. How did you update it? Manually?

Either way, this isn't your problem, so you can ignore this. I'll put in an issue to investigate.

[Xophmeister]

You are still missing a link, here. In markdown, enclosing text in square brackets [like this] is a shorthand for specifying a reference with the same text ([like this][like this]). When the reference is defined, the markdown is rendered as a link. Following our example, all of the following are equivalent:

### Shorthand form
[like this]

[like this]: http://example.com

### Expanded form
[like this][like this]

[like this]: http://example.com

### Link form
[like this](http://example.com)

### HTML form
<a href="http://example.com">like this</a>

If you scroll to the bottom of README.md, you'll see where all the references are defined. You should also define one for [cfml], pointing to an authoritative source of information on CFML.

[ghedwards]

Thanks for the feedback, spaces aren't something I had properly considered, I wonder if the tree-sitter-html grammar would suffer the same issue, it should just be text / content I'll have to have another look at the tree.

[Xophmeister]

Thanks for the feedback, spaces aren't something I had properly considered, I wonder if the tree-sitter-html grammar would suffer the same issue, it should just be text / content I'll have to have another look at the tree.

It's a good question. IIRC, spacing in HTML is usually non-semantic, except when it's part of a text node. That might be hard to accommodate in Topiary without text nodes in the grammar being specifically designed for Topiary-use...

[ghedwards]

Will Topiary not preserve space in text nodes ? Perhaps within but not at the start or end ?

[Xophmeister]

Will Topiary not preserve space in text nodes ? Perhaps within but not at the start or end ?

Topiary will apply the formatting rules that are defined in the queries and nothing else. If there's a space in the input, but the respective node does not have something like @append_space, then that space will not be there in the output. Topiary cannot assume anything about token/node boundaries -- because they're highly contextual -- so it relies entirely on the queries.

For some nodes, we expect the contents to be preserved verbatim (like strings). These get annotated with @leaf in Topiary queries. For Topiary to format HTML correctly, the grammar would have to be quite careful about where text nodes begin and end, such that the @leaf annotation will work correctly.

This is why I bring up the degree to which your queries cover the grammar: anything that's not covered can potentially be squished together. In some languages, this can result in an invalid output; which is obviously something we'd want to avoid.