Add semantic highlighting support for Dockerfiles

[rcjsuen]

With the finalization of the semantic highlighting API in Visual Studio Code 1.44, the Docker extension can now look to resolving long standing bug reports about malformed syntax highlighting in Dockerfiles using code instead of a TextMate grammar. I have tried to do a sweep of the GitHub issues that have been opened in the past to capture the various requests and bug reports about syntax highlighting in Dockerfiles.

• Add proper HEALTHCHECK colorization/intellisense #43 (request to add syntax highlighting for HEALTHCHECK flags)
• Syntax highlighting ENV and ARG references #90 (request to add syntax highlighting for ARG and ENV variables)
• Dockerfile syntax highlighting for escaped quotes is not quite right #75 (comment) (bug example)
• Dockerfile syntax highlighting for escaped quotes is not quite right #75 (comment) (bug example)
• Dockerfile syntax highlighting for escaped quotes is not quite right #75 (comment) (bug example)
• Dockerfile syntax highlighting for escaped quotes is not quite right #75 (comment) (bug example)
• Remapping of escape character not handled #245 (comment) (bug example)
• Syntax colorization stops working after RUN command in visual studio code with docker 0.0.27 plugin #292 (comment) (bug example)

Open question:
The extension currently depends on Visual Studio Code 1.41 which was released in December 2019.

vscode-docker/package.json

Lines 2439 to 2441 in 95fb889

	"engines": {
	"vscode": "^1.41.0"
	},

Adding semantic highlighting support will change this dependency to 1.44. Not sure to me how many users would be affected by this. Does Microsoft have telemetry information about this to know what percentage of this extension's users are on which release of Visual Studio Code?

[bwateratmsft]

I took a look at the last 24 hours, here's the numbers we have for Docker extension v1.0.0 users:

Version	Machine Count
1.44.0	31491
1.43.2	76223
1.43.1	3789
1.43.0	3316
1.42.1	3604
1.42.0	733
1.41.1	2469
1.41.0	306

These count the highest version a machine reported in the last 24 hours, i.e. people who have upgraded will only show up in 1.44.0.

The fact that the overwhelming majority of the numbers are in 1.43.2 or 1.44.0 tells me that nearly everyone stays up to date. I'll keep an eye on these numbers throughout the week, it hasn't even been 24 hours since 1.44.0 released so it can be expected to get even higher.

[rcjsuen]

@bwateratmsft The vscode.Terminal interface changed in 1.42 so the test/TestTerminalProvider.ts must be updated.

vscode-docker/test/TestTerminalProvider.ts

Line 36 in 95fb889

class TestTerminal implements vscode.Terminal {

[bwateratmsft]

Incidentally TerminalProvider is on its way out the door, #251

[dbreshears]

Let's monitor telemetry and wait for adoption of 1.44 to get closer to 80 to 90% and discuss before completed

[bwateratmsft]

We're nearly there already. This is among our extension version 1.0.0 users, last 24 hours:

Version	Count	% of Total
1.44.1	33316	25.6
1.44.0	64414	49.5
1.43.2	20371	15.7
1.43.1	2752	2.1
1.43.0	2695	2.1
1.42.1	3221	2.5
1.42.0	687	.5
1.41.1	2357	1.8
1.41.0	310	.2

1.44 already accounts for ~75%.

It's been ~5 weeks since 1.43.0 released, currently ~95% are >= 1.43.0. Our tentative plan for 1.2.0 release puts it at ~5 weeks after 1.44.0. So in theory that means when we release, we'll be at 95% upgraded.

[bwateratmsft]

@rcjsuen If you're ready, go ahead and prep a PR so we can get the change into the release as early as possible in the cycle. Thanks again!

[rcjsuen]

@bwateratmsft Sorry, perhaps I should have been more clear when I commented earlier.

Can someone fix these compiler errors first (which can be observed simply by changing the dependency to 1.42)?

[bwateratmsft]

Ah, yes, I'll be getting that fixed when I merge https://github.com/microsoft/vscode-docker/tree/bmw/terminals which should be soon, probably early-mid next week.

[bwateratmsft]

@rcjsuen You should now be unblocked. I upgraded the engine to 1.44 and fixed the bug (#1891); (though not by removing ITerminalProvider as originally planned, which ended up being nightmarishly complicated due to shell quoting issues).

[rcjsuen]

@bwateratmsft Thanks! I'll submit a pull request later today or tomorrow to enable semantic highlighting.

[rcjsuen]

@bwateratmsft I have opened #1899.

[bwateratmsft]

@rcjsuen We can close this now that #1899 is submitted, right?

[rcjsuen]

@rcjsuen We can close this now that #1899 is submitted, right?

@bwateratmsft I think we are good for the most part. Should I open a separate issue regarding the configuration of custom colours or should we just forget about it?

To everyone else, I'll reiterate what was posted in #1899 as a reference for toggling this with the JSON settings editor.

1. How do I enable/disable semantic highlighting?

   "editor.semanticHighlighting.enabled": true

2. How do I enable/disable semantic highlighting only for Dockerfiles?

   "[dockerfile]": {
       "editor.semanticHighlighting.enabled": true
   }

[bwateratmsft]

Should I open a separate issue regarding the configuration of custom colours or should we just forget about it?

@rcjsuen Yeah, I think that can be separate from this.

[rcjsuen]

Should I open a separate issue regarding the configuration of custom colours or should we just forget about it?

@rcjsuen Yeah, I think that can be separate from this.

@bwateratmsft OK. Let me do some research and then open an issue when I have something to share. I think we can close this then.

Thanks for your support and for answering the various questions I've been asking of you all!

[bwateratmsft]

Thank you for the language server!

[bwateratmsft]

This feature is now available in version 1.2.0 of the Docker extension.