FreeMarker with .ftlh and .ftlx extensions not identified as anything?

[chadlwilson]

FreeMarker templates can use output formats via file extensions, meaning a file that is .ftlh (FreeMarker Template Language - HTML) or .ftlx (FreeMarker Template Language - XML) is also FreeMarker, not just .ftl. Currently these don't seem to be identified as either FreeMarker OR HTML/XML respectively.

https://freemarker.apache.org/docs/pgui_config_outputformatsautoesc.html

Using the ftlh and ftlx file extensions is the recommended way of activating HTML and XML auto-escaping.

As above, this is the recommended usage with default configuration in FreeMarker 2.3.24+ (2018+).

I'm not sure what the desired behaviour would be from linguist's perspective, but do note that .erb seems to generally be considered HTML, rather than, say "Embedded Ruby (Template)".

Example
Can be tested with https://github.com/gocd/gocd (for the .ftlhs)

Currently github-linguist -b (7.24.1) reports the below, missing classifying this, and many others.

FreeMarker:
buildSrc/src/main/groovy/freemarker_implicit.ftl
buildSrc/src/main/resources/gocd-docker-agent/Dockerfile.agent.ftl
buildSrc/src/main/resources/gocd-docker-server/Dockerfile.server.ftl
server/src/main/java/freemarker_implicit.ftl
server/templates/macros.ftl
spark/spark-spa/src/main/java/freemarker_implicit.ftl

[lildude]

This is expected as Linguist only has the .ftl extension associated with FreeMarker (and knows nothing about the other two extensions):

https://github.com/github/linguist/blob/c1c34e5260797b4d598f5ec76f19723bfc5a1894/lib/linguist/languages.yml#L2009-L2018

It's been this way since it was implemented waaaaaay back when FreeMarker support was added in 2015 in #2689, which pre-dates the recommendation you mentioned by about three years 😁.

In order for these to be identified as FreeMarker, or similar, support will need to be added, assuming they are sufficiently popular for inclusion (see the CONTRIBUTING.md file to usage requirements).

I'm not sure what the desired behaviour would be from linguist's perspective, but do note that .erb seems to generally be considered HTML, rather than, say "Embedded Ruby (Template)".

Not quite. .erb has its own language entry so it can use it's own grammar, however it is grouped under HTML, hence you see it classified as HTML:

https://github.com/github/linguist/blob/c1c34e5260797b4d598f5ec76f19723bfc5a1894/lib/linguist/languages.yml#L2613-L2629

Something similar would be needed for .ftlx and .ftlh if they're popular enough for inclusion and need their own grammar in order to have the correct syntax highlighting, assuming the current XML and HTML grammars don't do a good enough job.

All support for languages is added by the community so if you've go the bandwidth, please feel free to submit a PR. If not, you can open an issue to add support and someone else in the community might spot the issue and be motivated to add support.

Until then, you can probably get good enough syntax highlighting by forcing the language to XML or HTML using an override. This might not be necessary for the .ftlx files if they've got a valid XML header as the current XML detection strategy will find this and automatically classifiy the files as XML.

[chadlwilson]

Yeah, thanks, I assumed it just wasn't handled. Opened a discussion as that's what it is suggested to do :-)

It'd be better to at least have the extensions classified under the existing freemarker, since the templating syntax is exactly the same anyway and it'd be better than nothing at all, even if its not the full highlighting.

[chadlwilson]

I suppose what I was asking for was whether this is something that'd be accepted as a change - but it sounds like it would be, pending the usage requirements (which will be easily met - especially for just the file extension stuff).

[lildude]

Yes, if the usage requirements are met, we can add support. One word of caution about:

It'd be better to at least have the extensions classified under the existing freemarker, since the templating syntax is exactly the same anyway and it'd be better than nothing at all, even if its not the full highlighting.

The templating syntax might be the same, but the additional XML and HTML tags are likely to make the resulting syntax highlighting messy (which will result in issues and support tickets) unless the grammar supports them which I doubt is the case with the currently used grammar as it hasn't been updated since 2015. If you can find a grammar that supports all supported file formats for FreeMarker, then you can switch out the current grammar as part of the same PR.

[chadlwilson]

Freemarker is an arbitrary text templating language so there is not really any limit on file formats. It just has some special escaping support for some things rather than others if you declare the format.

If templating HTML or XML, many people will already be using .ftl extensions anyway. Templating such formats has been a very common Freemarker use case forever, since it was available as a view renderer for server-side markup within Java web frameworks for a long time. The extension-based indication is just a newer capability to avoid having to declare output formats (and required escaping) in the earlier ways - it's unlikely to have had any effect on how likely it is that people choose to template HTML/XML with FreeMarker (or not).

At this stage I don't see why it'd be any worse from a support perspective than the current highlighting capability limitations.

[lildude]

Ah. I wasn't aware of that (I know diddly about FreeMarker 😆). In that case, I think we can probably go with simply adding the extensions that meet the usage requirements.