Sysmagine / SemanticDiff

Community support for SemanticDiff, the programming language aware diff for Visual Studio Code and GitHub.
https://semanticdiff.com
40 stars 0 forks source link

All code coloring lost. #56

Open engrogerio opened 4 months ago

engrogerio commented 4 months ago

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

slackner commented 4 months ago

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 commented 4 months ago

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 commented 3 months ago

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

mmueller2012 commented 3 months ago

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 commented 2 months ago

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).

slackner commented 2 months ago

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 https://github.com/microsoft/vscode/issues/145307 is fixed, we may be able to revert to the old behavior, if there is a preference.)

thepycoder commented 2 weeks ago

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 commented 2 weeks ago

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.