PlantUMLServer render mode not working in remote Windows WSL projects

[abulka]

Being able to change render mode away from local to PlantUMLServer works OK in local projects but fails when editing remote WSL projects.

Whilst I can install the vscode-plantuml extension in a remote WSL, it only works in local mode, which is where the extension builds diagrams by running the plantuml command, which needs java and graphviz.

The usual render mode setting is missing from the remote plantuml settings UI, so I cannot change mode. The render mode UI options appear OK in local projects in windows, but not in a remote WSL project. Forcing the matter and manually editing settings.json,

    "plantuml.render": "PlantUMLServer",
    "plantuml.server": "http://localhost:8080/plantuml"

did not work either, and those settings appear dimmed and refuse to be applied, with the hover error:

This setting cannot be applied in this window. It will be applied when you open local window.

Is this a known issue or am I missing something? I'd like to get the improved speed of "PlantUMLServer" mode when editing in my WSL based projects.

[robert-shade]

Did some digging on this - this is because 833bdee set the extensionType to ["workspace", "ui"]. This gives it the option to run remote or local. However, several configuration values (like .render and .server) are machine-overridable scoped. This will allow you to set them in your user settings when running locally, but will ignore the user settings when in remote mode. You have to use the remote settings in that case.

Unfortunately, since the extension is allowed to run locally, you end up in a situation when using remote WSL/SSH/Docker where the user level setting is ignored and the extension doesn't consult the remote config, because it's running locally.

I think the fix to this is to set extensionType to workspace. @qjebbs ?

[qjebbs]

Informations about this issue:

• Why I choose ["workspace", "ui"]: VS Code Server: define execution location #282 (comment)
• What the setting overridable logic expected (decided by where the extension runs):
  • Flag machine specific configurations like paths as machine scoped #239 (comment)
  • Support machine-specific settings that can be set (overridden) in workspace/folder microsoft/vscode#73985 (comment)

But, seems setting overrides are decided by where the workspace located.

According to former information, my vision is to make the extension works both on remote and local. Remote mode first, then local mode if remote not installed.

As to the current override logic, ["workspace", "ui"] is not applicable to this extension. If VSCode not willing to change the override logic, I will set extensionType as workspace, to make things simple. In other words, users have to install the extension everywhere.

[qjebbs]

BTW, Workarounds for you, even I don't change the extensionType:

@robert-shade Install extension on remote will solve your problem, you still have to do so, after the extensionType changed.
@abulka Install extension on remote, and edit remote settings, not local settings.

I still hope VSCode will update/extend the setting override logic, to make the extension works both on remote and local.

[robert-shade]

@qjebbs confirmed that 2.13.12 fixes this. It's a bit awkward that you have to configure the renderer in both your user and remote settings to handle both local and remote use cases, but that's a core VSCode issue.