You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
First, thank you for creating this very helpful, fantastic plugin. I am using it extensively across several projects and it is invaluable.
I have run into a couple of !include issues when embedding plantuml in markdown documents and trying to preview the result in the default VS-Code Markdown Preview. After poking around a bit, I think that the issues are because when rendering in combination with the markdown preview, the plugin seems to ignore the plantuml.render: Local setting and use server rendering anyway and the server rendering does not seem to understand !include paths.
I am using Local to be able to pass values to plantuml.include.path and making the setup match the mkdocs document compilation environment for publishing.
Any hints for how to solve or work around this problem would be greatly appreciated.
The problem I am having:
In the markdown preview, !include only works when:
The including file provides the absolute path from the root of the filesystem.
The value of the !include parameter is the literal file path and not one composed using Plantuml variables
These cases work fine for "naked" Plantuml preview.
There are a couple of additional quirks of the "naked" Plantuml Preview when using Local setting, found while trying to sort out what was going on:
%dirpath() does not work.
When getting the PWD environment variable, the plugin reports the working directory to be the root of the file system.
If the plantuml.includepaths setting includes the absolute path from the root of the filesystem to the directory where the files are located, the plugin works.
There is still the difference in that when rendering inside markdown, it does not recognize the local directory as an origin for include files.
First, thank you for creating this very helpful, fantastic plugin. I am using it extensively across several projects and it is invaluable.
I have run into a couple of
!include
issues when embedding plantuml in markdown documents and trying to preview the result in the default VS-Code Markdown Preview. After poking around a bit, I think that the issues are because when rendering in combination with the markdown preview, the plugin seems to ignore theplantuml.render: Local
setting and use server rendering anyway and the server rendering does not seem to understand!include
paths.I am using
Local
to be able to pass values toplantuml.include.path
and making the setup match themkdocs
document compilation environment for publishing.Any hints for how to solve or work around this problem would be greatly appreciated.
The problem I am having:
In the markdown preview,
!include
only works when:!include
parameter is the literal file path and not one composed using Plantuml variablesThese cases work fine for "naked" Plantuml preview.
There are a couple of additional quirks of the "naked" Plantuml Preview when using
Local
setting, found while trying to sort out what was going on:%dirpath()
does not work.PWD
environment variable, the plugin reports the working directory to be the root of the file system.Environment
Machine
VS-Code
Version
Workspace settings
Structure of the VS-Code workspace
Info to reproduce the problem
Markdown File with embedded Plantuml (
test.md
)With a bunch of output in the title for diagnostics.
You can reproduce the problem by toggling the variables:
toggle_relative_path
toggle_composite
Two minimal plantuml files to include
File sampleclass.puml
File sampleclass2.puml
Working Output (no relative include paths, no composition of
!include
arguments)Note that there are some weird discrepancies in the rendering of tabs, but that is minor...
From the Plantuml Preview window
This is using
Local
renderingFrom the Markdown Preview window
And for "golden" reference, the command line result
with this executed from the workspace root:
Errors Found
With
$toggle_composite == 1
With
$toggle_relative_path == 1
The text was updated successfully, but these errors were encountered: