Diff tabs opened from the `Source Control` panel no longer in preview mode

[cateyes99]

• VSCode Version: 1.12.1
• OS Version: OS X EI Capitan 10.11.3

Steps to Reproduce:

1. Open some project from GitHub.
2. Make some changes to a file A.cs, and save it.

3.a Stay on the editor of A.cs, and click the button of Open Changes on the top right corner above the editor.
4.a A diff tab opened to show the difference between the changed A.cs and the version in GitHub. Before version 1.12, this diff tab will be open in the preview mode (the tab title font is in italic), now the new diff tab is just a normal tab.

3.b Open the Source Control panel, click A.cs.
4.b A diff tab opened to show the difference between the changed A.cs and the version in GitHub. Before version 1.12, this diff tab will be open in the preview mode (the tab title font is in italic), now the new diff tab is just a normal tab.

5. If I have 50 files changed, and iterate the changes in the 50 files from Source Control panel, it will open 50 diff tabs for me! This new behaviour isn't very desired. The old behaviour in the previous versions is much more convenient and consistent with opening files from the Explorer panel.

[eamodio]

FYI, this changed here: 9f01642#diff-5d0a5d79d21dddf1284ed8ca92298d24R384

[joaomoreno]

cc @jrieken already 4 users mentioned this

[jrieken]

This was to align the behaviour of our various open-calls. @joaomoreno you do have an option tho, simply set preview to true and everything is back to normal

[bpasero]

I think the extension should not decide to set the preview flag unless it really wants to make sure that something does not open as preview (e.g. a use case I can see is to open a playground to the side of the current editor that should not go away too easily).

The workbench should deal with the preview flag, otherwise settings like "workbench.editor.enablePreview": false are ignored, which is bad.

[bdinesh]

@jrieken I have set "workbench.editor.enablePreview": true in user settings but no luck. Is there any other setting to be set explicitly?

[jrieken]

This isn't about the setting @bdinesh. Foremost extensions can express their intent when showing a text document (preview or not). Unsure how the setting plays into that, but I have a feeling that the editor service should use it and simply overrule the API choice. Correct @bpasero or are there editors that must open as preview despite have that setting which blocks putting this into the service?

[bpasero]

@jrieken @joaomoreno today we have two settings that play a role to decide if an editor should open as preview or not:

• workbench.editor.enablePreview (default: true)
• workbench.editor.enablePreviewFromQuickOpen (default: true)

If these settings are configured by default, in most cases we open files in preview (e.g. click in explorer, open from quick open).

However, there are still some user interactions that can lead to not using preview after all independent from the setting:

• double click in the explorer
• opening a dirty file
• moving a file from the explorer

If the workbench.editor.enablePreview setting is configured to be false you will never see an editor as preview no matter how the user configured it from the API.

If the workbench.editor.enablePreviewFromQuickOpen setting is configured to be false, it only impacts editors that open from quick open but nothing else.

My understanding is that we added new API for TextDocumentShowOptions to control if a document opens as preview or not. However, we are not having this option from our vscode.diff command, and as such there we now hardcode pinned: true. Wouldn't it best we do not set pinned at all for any editor we open from extensions and let the extension decide this? For example, we could add support for the vscode.diff command to define similar TextDocumentShowOptions and then the GIT extension can actually decide to open pinned or not based on user interaction (e.g. double click vs. single click).

[jrieken]

However, we are not having this option from our vscode.diff command, and as such there we now hardcode pinned: true.

No, that isn't correct. We have added that option when adding the option for showing a text document. The change that happened is that both are now aligned wrt the default, which is 'pinned'. The diff-command used to be different here and because it is less official got aligned with the show-function. To get to old behaviour you need to pass {preview: true} when calling the diff-command.