Closed msujew closed 2 weeks ago
If I understand correctly, the idea of this workaround is to delay notifications through the editor service until the tabs main service has had time to update the tab info, right? The problem seems to arise because we state (editor state, tab groups) that needs to be update "atomically" in order to not present an inconsistent picture to clients. However, since we're using independent widget listeners to trigger updates to various components, we can't sequence the actions properly. To me it sounds as if we needed to introduce a single coordinator object that listens to the widget changes and then orchestrates the proper sequence of updates. Once the local state is consistent again, we can replicate the state to the back end/plugin host. Your thoughts?
@tsmaeder My thoughts exactly, see the follow-ups section of the PR. There would only be a single service that would fire events in the expected order while also correctly keeping track of the tabbars/viewcolumns.
What it does
Works around (but not actually closes) https://github.com/eclipse-theia/theia/issues/13679
This fixes the tab group API event order and ensures that the tab groups are always up-to-date on the plugin host by delaying the triggering of other events like
onDidChangeActiveEditor
.This also sets all columns of groups to
0
. This should at least work around https://github.com/eclipse-theia/theia/issues/13679. See follow ups for more details on this.How to test
Follow-ups
The implementation of the
ViewColumnService
hasn't been kept up-to-date with the current requirements of Theia or VS Code. For example, it isn't aware of the position of tab groups (only of tabs) or of floating editor windows. And even for those tabs, it yields very much unexpected values. This needs an entire refactoring using something similar like VS Code'sEditorGroupService
implementation.I'll probably get to this in a separate PR, but that's a larger issue so I'm not sure when I'll be able to do that.
Review checklist
Reminder for reviewers