workspace.openTextDocument opens second editor window

[kburtram]

• VSCode Version: 1.12 insiders
• OS Version: Windows

Steps to Reproduce:

1. Open a text file in one split window pane
2. Focus another text file in the other spilt window pane
3. Run an extension command workspace.openTextDocument with URI from file from step 1

Expected: Focus is returned to existing open file from step 1

Actual: A new editor instance is opened in the split window pane from step 2. Net results is two editor windows open with same URI. One editor in each of the split pane windows. This is a change in the openTextDocument behavior in the insiders build.

Additional note: This is impacting the mssql for VS Code extension which has a link in the query results window that refocuses to the correct lines in the SQL file. Instead of refocusing to the existing SQL editor, now a new editor window is opened.

[jrieken]

this is a regression from b5340db#diff-5c241ba7b54b0818cea62f7130c9082d

[bpasero]

@kburtram trying to understand your scenario here: it is actually normal behaviour of code to open documents in the column that is currently active. if people do not like that, we have a setting "workbench.editor.revealIfOpen": true that allows to change this behaviour as needed. Also, as an extension you could explicitly always set the view column via options if you think that your documents should always open in column one.

In any case, I think the fix here does not make sense: if I am in column 2 and I open a document in column 3 and now workspace.openTextDocument gets called with the file of column 2 it would open in column 1?

[kburtram]

@bpasero it's been a little, but as I recall, there was a change in vscode behavior in a particular insiders build regarding openTextDocument behavior.

At a high-level I can describe our use-case. We open a preview window for query results that is associated to a particular SQL text editor window. In the preview window there is an HTML link that we use to select text in the SQL text editor and bring the text editor into focus. Currently we use openTextDocument to bring the existing text editor into focus.

In the insiders build related to this issue, the behavior of openTextDocument changed to no longer bring the existing editor into focus, but opened a new duplicate editor window in the same column as the preview window (which we explicitly try to open in a different column then the text window unless the user manually repositions the documents). It was the duplicate editor that was the core issue, not really the which column the document was opened in.

Basically, we want a way to either reveal the existing SQL text window associated with a particular preview window if it is already open, or to open a new SQL text window for the particular file if the editor has been closed. Preferably the SQL text window would open in a different column then the preview window. This was the behavior we were getting from our usage of openTextDocument prior to this issue and the fix restored that behavior.

We can update the extension if there is a better way to accomplish this goal, but having two SQL editor windows open when clicking on the link in the preview window didn't really provide a good experience for the user. Please let me know if you need more details on our scenario or API usage.

[kburtram]

@kevcunnane please watch this issue in case there are any API changes we need to react to.

[bpasero]

@kburtram thanks for the explanation, I do not think we would change existing behaviour. But for some extensions the desire is to open an editor in the currently active view column, so we might have new API to get there.

[bpasero]

@kburtram with #34459 I would like to change this behaviour because for extensions there is always a workaround to force open an editor in the first view column via ViewColumn.ONE as argument to the open call. Is that working for you?

[kburtram]

@bpasero from the discussion this change sounds fine. I'll test the mssql extension with the latest insiders build this weekend and get back to you.