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 ( microsoft/vscode#228270) with some small sample code to reproduce the problem. Hopefully this will help them fix it quickly.