-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[vscode] Support TextEditor#show() and TextEditor#hide() #11146 #11168
[vscode] Support TextEditor#show() and TextEditor#hide() #11146 #11168
Conversation
@@ -168,6 +169,19 @@ export class EditorsAndDocumentsMain implements Disposable { | |||
saveAll(includeUntitled?: boolean): Promise<boolean> { | |||
return this.modelService.saveAll(includeUntitled); | |||
} | |||
|
|||
hideEditor(id: string): Promise<void> { | |||
for (const editorWidget of this.editorService.all) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Before trying to remove this loop, is there an existing way to get the EditorWidget for a MonacoEditor that I have missed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since the editor data reported to the plugin side has gone through the EditorSnapshot
system, I don't really see a way recover the editor meant other than to repeat the process.
a52d3bf
to
0ea2088
Compare
As far as I can tell this is also the same behavior in VS Code. Splitting a
How would we test this?
How would we test this? |
@@ -1157,11 +1157,11 @@ export interface DecorationOptions { | |||
} | |||
|
|||
export interface TextEditorsMain { | |||
// $tryShowTextDocument(resource: UriComponents, options: TextDocumentShowOptions): Promise<string>; | |||
$tryShowTextDocument(uri: UriComponents, options?: TextDocumentShowOptions): Promise<void>; | |||
$registerTextEditorDecorationType(key: string, options: DecorationRenderOptions): void; | |||
$removeTextEditorDecorationType(key: string): void; | |||
// $tryShowEditor(id: string, position: EditorPosition): Promise<void>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we implement / delete this variant?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will remove it. Looking at the arguments the idea might have been to show/split an existing editor to a tab bar.
I think this can be achieved with tryShowTextDocument
as well
@@ -168,6 +169,19 @@ export class EditorsAndDocumentsMain implements Disposable { | |||
saveAll(includeUntitled?: boolean): Promise<boolean> { | |||
return this.modelService.saveAll(includeUntitled); | |||
} | |||
|
|||
hideEditor(id: string): Promise<void> { | |||
for (const editorWidget of this.editorService.all) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since the editor data reported to the plugin side has gone through the EditorSnapshot
system, I don't really see a way recover the editor meant other than to repeat the process.
Only one preview can be open at all. If any other editor is opened as a preview, the old preview will be closed and the new preview will replace it. Details here. It appears that VSCode allows one editor preview per column, rather than one total.
That appears to be a consequence of the implementation of
Based on the code in the method referred to above, this looks like it should work: if the column exists, the active editor in that column should be used as the ref for opening the new widget. I would guess that this is a consequence of the multi-editor tracking system: at the moment, the only way to force a new editor to open with the same URI as an existing editor is to go through the |
I've pushed a commit here that should get the behavior closer to VSCode. Feel free to use it if it suits your needs.
|
0ea2088
to
44dab0c
Compare
Thank you @colin-grant-work . With your commit (which also addresses your suggested change in Can I cherry-pick your change to this branch? |
Yes, by all means, feel free. |
44dab0c
to
4ab2638
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jfaltermeier @JonasHelming I'm not sure about implementing the deprecated
api, can't we just stub it? Extensions really shouldn't be using this API and it has been deprecated in VS Code from what it seems like the start (when it was public). I traced the deprecation back 7 years:
this.all.forEach((editor: EditorPreviewWidget) => { | ||
if (editor.isPreview) { | ||
editor.convertToNonPreview(); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe we should check the preference name before we perform this operation since it might be expensive.
At the moment EditorPreviewPreferences
only has the one preference but this might change in the future and better to be defensive.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, I've added the check
@vince-fugnitto I agree that we should not spent much effort into fully implementing deprecated API. Here the actual implementation of the deprecated api is not a big code change however (see the first commit): fda5937 |
@jfaltermeier but rather than do fda5937 at all and include code that is only triggered by deprecated API we can simply stub it (minimal changes). Do we really want to maintain an API that has been deprecated for so long? I see value in closing the gap for the differences (other commit) but implementing the |
@jfaltermeier @colin-grant-work if you still feel like the deprecated methods should in fact be supported then please disregard my comments :) I just thought it was a little odd to actually support the api given it was deprecated from the start. |
I think I'm inclined to merge the implementation. It's strange that VSCode included deprecated API in their first public commit, and even stranger that they haven't removed it in the intervening 7 years, but as long as we've committed to supporting the VSCode plugin API, we should not reject a sound implementation, even of deprecated API. |
@jfaltermeier for the theia: vscode: Steps:
|
I'm on vacation until June 7th. I will pick this up again when I'm back. |
432feed
to
37dc356
Compare
This should work now. In case of |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I confirm that the changes work as expected, I did not notice any regressions 👍
@colin-grant-work : Fine if we merge this? |
Ok with me. 👍 |
@jfaltermeier : Please resolve conflict and merge ;-) |
…a#11146 * extends theia.d.ts accordingly * adapt editor-manager to handle split editor open-request with missing counter option by computing the counter * add show/hide to TextEditorsMain interface Signed-off-by: Johannes Faltermeier <jfaltermeier@eclipsesource.com> Contributed on behalf of STMicroelectronics
* instead of falling back to split-right, compute the actual column index where the editor shall be shown * this will focus an existing editor for the file in the next tabbar if existing instead of always showing a new editor Signed-off-by: Johannes Faltermeier <jfaltermeier@eclipsesource.com> Contributed on behalf of STMicroelectronics
37dc356
to
3e3f0af
Compare
Ref: eclipse-theia/theia#11168 Signed-off-by: Akos Kitta <a.kitta@arduino.cc>
Ref: eclipse-theia/theia#11168 Signed-off-by: Akos Kitta <a.kitta@arduino.cc>
Ref: eclipse-theia/theia#11168 Signed-off-by: Akos Kitta <a.kitta@arduino.cc>
What it does
Add support for
TextEditor#show()
andTextEditor#hide()
VSCode-behaviour:
When using
TextEditor.show(ViewColumn)
VSCode opens the editor again in preview-mode.When using a numbered ViewColumn it brings the editor to the front, if existing, or opens it in the respective column. If the column is not existing it will be created.
TextEditor.hide() closes the editor.
Gif from VSCode with below extension:
fixes #11146
Contributed on behalf of STMicroelectronics
How to test
I've created a small vscode-extension that used the API here: https://github.com/jfaltermeier/vscode-playground/blob/f290f4b2f00cc3460e45b525eb822fe6824d986d/text-editor-show-hide/src/extension.ts
The vsix may be downloaded from here: https://github.com/jfaltermeier/vscode-playground/releases/tag/text-editor-show-hide-0.0.1
Start Theia with this extension and try the "Test show editor beside", "Test show editor in column one", "Test show editor in column two", "Test show editor in column three", and "Test hide editor" commands.
These work on the
vscode.window.activeTextEditor
.Review checklist
Reminder for reviewers