Detecting all different types of .htm files

[arvislacis]

First of all, this is not a real issue but more like a conceptual discussion and comments. Although maybe something could be done/improved in the extension logic or at least maybe README could be updated with settings I will give below. Also I am aware that this is only Preview version of extension so probably you are also aware of this.

Anyways, I installed extension yesterday and played around it a little - Winter CMS page file (.htm) detection works as expected but problems start to arise when I open, for example, component, partial and controller .htm files - by default (at least in my VSCode setup) they are also detected as Winter CMS Template files but as they don't contain == delimiters and are not true Winter CMS files but more like standart html files then syntax highlighting gets messed around and doesn't work for html code in the files:

So my workaround at this problem was to update my VSCode workspace file association settings (.vscode/settings.json file):

{
    "files.associations": {
        "*.htm": "wintercms",
        "**/controllers/**/*.htm": "html",
        "**/components/**/*.htm": "wintercms-twig",
        "**/partials/**/*.htm": "html"
    }
}

And now the syntax highlighting looks like this for the same component file:

I didn't tested my setup in all scenarios and I know that it's not 100% safe because, for example, partials can also contain YAML section with description field but so far looks and works at least better than default auto-detection feature for component, partial and controller html files.

[LukeTowers]

@arvislacis All new WinterCMS projects have smart extension mapping by default, but if you'd like to add it to your existing projects you can copy the .vscode/settings.json file from the main repo to your project: https://github.com/wintercms/winter/blob/develop/.vscode/settings.json.

[arvislacis]

@LukeTowers Nice, thanks for the clarification. Yeah, my projects are from the previous year so these settings are not up to date. But, anyways, maybe there could be some note in extension's README file about this...

[arvislacis]

@LukeTowers I looked into the Winter CMS config you mentioned and now I have question about this:

https://github.com/wintercms/winter/blob/cf5ae34f5adfa17f18d7f8f381a2fc73330b744a/.vscode/settings.json#L14

Shouldn't it be wintercms-twig instead of twig?

[LukeTowers]

Component partials are only Twig, they don't have INI or PHP sections.

@bennothommo is wintercms-twig a mode that's different from twig and wintercms?

[bennothommo]

@arvislacis thanks for the report - yes, I've encountered this issue too.

The reason for this is due to an intrinsic design decision of the syntax highlighter that VSCode uses - TextMate. TextMate is performant for one simple reason - it applies syntax per line, not over the entire document. You can set boundaries for embedded languages (in our case, INI and PHP), but ultimately, the first match always wins unless it is ended. There is no mechanism to deny a section once it has begun - it will apply that section until it hits the end boundary, or it hits the end of the document.

We have set up our syntax (the wintercms language) to always assume that there is always an INI section, there may be a PHP section, and the HTML/Twig section will always be last. With this assumption, our syntax highlighter works flawlessly with compound templates - the two attempts that have tried to bring language support to October require something to be added to the template for all three languages to work. But this does have the effect that in straight HTML/Twig templates, these are interpreted as INI files because it never hits the "end" boundary for that section (the == characters).

I'm in two minds on whether this needs to be fixed - on the one hand, our templates always have these boundaries if they are created through Winter, so implicitly this is the correct format, but on the other hand, it's not a requirement - straight HTML/Twig files load up just fine in Winter.

It could be that we simply recommend people start their templates with two equals (==) and then go ahead with the HTML/Twig code, or we recommend people who want to edit a straight HTML file switch the language to the "Winter CMS Template (Twig)" language. Happy to hear other thoughts on this though.

@LukeTowers

@bennothommo is wintercms-twig a mode that's different from twig and wintercms?

It's our version of the Twig language, which also adds highlighting for our functions and filters too. It has to be specified in order for the embedded Twig in our compound templates (powered by the Winter CMS Template language) to work.

[arvislacis]

It's our version of the Twig language, which also adds highlighting for our functions and filters too. It has to be specified in order for the embedded Twig in our compound templates (powered by the Winter CMS Template language) to work.

If that's the case then shouldn't https://github.com/wintercms/winter/blob/cf5ae34f5adfa17f18d7f8f381a2fc73330b744a/.vscode/settings.json#L14 be changed to wintercms-twig?

[bennothommo]

Yeah, it should be that, but I'll test it first before changing it :)

[arvislacis]

At least it worked for me without problems. :) And also, if this extension is mostly managing all Twig syntax etc. of Winter CMS projects then I don't see point of using twig (probably another extension) just for component partials.

[arvislacis]

@bennothommo Did you take look at that https://github.com/wintercms/winter/blob/869a718feeba4da82b06d92a0b7f547747ef4af7/.vscode/settings.json#L14 config?

[bennothommo]

@arvislacis thanks for the reminder. Will fix that in the repo. :)