Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

All code coloring lost. #56

Open
engrogerio opened this issue Mar 19, 2024 · 8 comments
Open

All code coloring lost. #56

engrogerio opened this issue Mar 19, 2024 · 8 comments
Labels
bug Something isn't working vscode The issue is related to our VS Code extension

Comments

@engrogerio
Copy link

engrogerio commented Mar 19, 2024

When I enable SemanticDiff for a Python file , all code coloring is lost no matter the color theme I use.
When I disable, all colors are back.
I have the folowing vscode extensions related to Python enabled:
Pylance, Python, Python Debugger and Python Indent.

SemanticDiff v 0.8.8
VsCode 1.87.1

SemanticDiff disabled:

image

SemanticDiff enabled:

image

@engrogerio engrogerio added bug Something isn't working github This issue is about our GitHub App labels Mar 19, 2024
@slackner
Copy link
Contributor

Thanks for reporting this issue.

Do you use a Dev Container by any chance? I suspect you are running into this issue we mentioned in the README:

When running SemanticDiff in a Dev Container, syntax highlighting is not working properly yet.

We've already analyzed this problem, and it's caused by SemanticDiff not being able to see any other extensions when using a dev container setup. There is actually a VS Code API proposal that would fix this.

We'll have to wait for this proposal to be accepted before we can use the feature in our VS marketplace extension, unfortunately.

Best Regards,
Sebastian

@asford
Copy link

asford commented Mar 26, 2024

Is it expected that syntax highlighting also fails in any remote editor setup?
I.e. running in any of (dev containers, ssh remotes, wsl2 remotes)?

@thepycoder
Copy link

I have the same in an SSH environment, so it seems likely to be as @asford suggests, connected to any remote setup

@mmueller2012
Copy link
Contributor

The problem occurs when the VS Code server and the user interface are running on different hosts (including VMs or containers). This applies to all scenarios listed by @asford.

SemanticDiff runs on the same machine as the VS Code server and cannot enumerate the syntax highlighting extensions. So it displays the diff without colors. As noted by @slackner, there is an API proposal that has been open for 2 years that would fix this, but there doesn't seem to be any progress.

We could move the computation to the client side (UI). However, this may lead to longer waiting times depending on how powerful the client is compared to the server. This compromise may be a better solution than no syntax highlighting at all. We will give it a try and see if it makes sense to include this change in the next release.

@mmueller2012 mmueller2012 removed the github This issue is about our GitHub App label Apr 10, 2024
@mmueller2012
Copy link
Contributor

I just verified that changing the extensionKind to "ui", "workspace" fixes the problem. This will have performance implications for thin client like setups but it is probably still better than having no syntax highlighting. The fix will be part of the next release (sometime within the next 2 weeks).

@mmueller2012 mmueller2012 added the vscode The issue is related to our VS Code extension label May 3, 2024
@slackner
Copy link
Contributor

We've just released SemanticDiff 0.8.10, which should fix this.

As Michael suggested above, we've changed the extensionKind to ["ui","workspace"] so that we can enumerate and access locally installed syntax highlighter plugins even in a remote editor environment.

Depending on the exact use case, this may also have some drawbacks. Diff computation may be slower on systems with very few resources, as the remote environment is no longer being used. For dev containers, on the other hand, it may be slightly faster.

Does the latest version fix the problems for you?

(Just for reference, once microsoft/vscode#145307 is fixed, we may be able to revert to the old behavior, if there is a preference.)

@thepycoder
Copy link

I'm not OP, but had the same issue and it is indeed fixed. Thank you very much. That fact that it's possible to revert to old behaviour might make it interesting to add an option for the user to choose?

Intuitively though, I had always thought this kind of thing was front-end anyway, it feels almost like a UI feature...

@mmueller2012
Copy link
Contributor

I'm not OP, but had the same issue and it is indeed fixed. Thank you very much. That fact that it's possible to revert to old behaviour might make it interesting to add an option for the user to choose?

Unfortunately, this is not possible. The extensionKind option is a static value in the extension description and cannot be changed at runtime.

Intuitively though, I had always thought this kind of thing was front-end anyway, it feels almost like a UI feature...

Kind of. Calculating a diff requires access to the underlying files, and can be computationally expensive. It makes sense to do it in the "backend". Rendering the diff with its UI elements certainly belongs in the frontend. But you can't split an extension like that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working vscode The issue is related to our VS Code extension
Projects
None yet
Development

No branches or pull requests

5 participants