SemanticDiff does not open by default on unsupported files

[craiganderson-iotv]

Describe the Bug

When opening a diff for an unsupported file type, SemanticDiff does not open, despite the semanticdiff.defaultDiffViewer setting being enabled.

To Reproduce Steps to reproduce the behavior:

1. Enable semanticdiff.defaultDiffViewer
2. Open a diff for an unsupported file type, e.g. .md
3. SemanticDiff does not open by default

Expected Behavior SemanticDiff should attempt to open for all files, or at perhaps the setting should be adjusted to be "open by default for supported files"

Actual Behavior SemanticDiff only opens by default for supported files

SemanticDiff Version v0.9.0

VS Code Information

Version: 1.93.0
Commit: 4849ca9bdf9666755eb463db297b69e5385090e3
Date: 2024-09-04T13:02:38.431Z
Electron: 30.4.0
ElectronBuildId: 10073054
Chromium: 124.0.6367.243
Node.js: 20.15.1
V8: 12.4.254.20-electron.0
OS: Linux x64 6.8.0-40-generic snap

[mmueller2012]

Our diff viewer lacks some features that are available in the standard diff viewer (such as text editing). So we assumed that developers might be more interested in using the standard viewer if we cannot provide a semantic diff, and deliberately implemented this behavior. However, it should be easy to make this configurable. We can probably add such an option in the next release.

Just out of curiosity: Why do you prefer the SemanticDiff viewer for unsupported files?

[craiganderson-iotv]

Thanks for the quick response!

Your reasoning makes sense, it would be nice if the setting description / name reflected that behaviour, too.

I would prefer either always-default or always-optional for a few reasons:

• Even on unsupported files, SemanticDiff does a reasonable job of filtering out whitespace changes
• I use a mix of supported and unsupported files, and it is somewhat jarring to have two slightly different UI's presented, depending on the file, i.e. I would prefer consistency over compatibility

On a similar note, the semanticdiff.closeOriginalTab setting does not appear to work, though I'm unsure if my VS Code settings or something else is preventing it from seamlessly working

[mmueller2012]

On a similar note, the semanticdiff.closeOriginalTab setting does not appear to work, though I'm unsure if my VS Code settings or something else is preventing it from seamlessly working

I can also reproduce the problem. However, it seems to be more of a bug in the VS Code extension API. It works fine with older versions of VS Code and broke somewhere between version 1.89.1 and 1.90.2.

Based on my debugging, it seems like the tab list gets corrupted when opening a webview. I have opened a bug report ( https://github.com/microsoft/vscode/issues/228270) with some small sample code to reproduce the problem. Hopefully this will help them fix it quickly.

[mmueller2012]

We just released SemanticDiff 0.10.0 which should fix both of the issues you reported.

You can now make SemanticDiff the default diff viewer for all file types by selecting the following value from the option dropdown:

We also added a workaround for the tab close bug in VS Code. Enabling semanticdiff.closeOriginalTab should now close the tab again.

Would be great if you could give it a try and confirm that it works :-)

[craiganderson-iotv]

Thank you very much, I am happy to confirm that it is indeed working! SemanticDiff opens by default, and the original tab does correctly close each time.

My last note is that tabs opened by SemanticDiff are not temporary: Usually opening diffs in VS Code will have the title in italics, and will be replaced when you open another diff, which makes it easy to flip through a whole bunch of changed files without opening each as a new tab.

SemanticDiff tabs are non-italic, and do not behave as a temporary tab.

I presume this is most likely a VS Code limitation rather than anything you've done, and overall it's probably not worth the effort.

(I love the minimap view as well, it's a fantastic addition!)

[mmueller2012]

My last note is that tabs opened by SemanticDiff are not temporary:

This is already covered by issue #61. The VS Code extension API only supports creating preview tabs for standard text documents. As you already guessed, we cannot really fix this :confused:.