You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It's possible to use core sublime project management commands, other plugins, or a non-hot exits to introduce state inconsistencies in Constellation (i.e., Constellation thinks constellation X is open, but none of the projects are). I haven't taken much action here yet in part because it seems like a non-serious issue that could be a real time-sink, and also because it seems easy to rush down the wrong path.
It's probably possible to use some events and start making heuristics for whether to mark a constellation open or closed, but the definitions seem a little slippery once you look at them up close:
If you use the project menu or subl command to open a project that happens to be in a 1-project constellation, is the constellation "open", or not?
If you open a 2-project constellation, then use the project menu to close one project, is the constellation still open? If you hot-exit and reopen sublime (with one of the two projects open), is the constellation open or closed?
If you use the project menu to manually open every project in a 5-project constellation (but never use Constellation's menu to open it), do we consider the constellation to be open?
I added the notion of "open" constellations as a first step towards making Constellation's internal state more transparent via menus, and to avoid presenting silly menu options (like showing the option to open a constellation that is already open).
It's possible that this was the mistake here, and that the change should be to do away with the notion of a constellation itself being open or closed. It might ultimately yield a simpler and more transparent plugin if we treat each constellation more as a set of commands (open these projects if they are closed; close these projects if they are open). In this model, instead of introducing more transparency by tracking and exposing state, transparency would just mean exposing the effect of the sets of commands (this command would open these 4 projects, but they're all already open; this command would close these 3 projects, but only this 1 is open).
The text was updated successfully, but these errors were encountered:
It's possible to use core sublime project management commands, other plugins, or a non-hot exits to introduce state inconsistencies in Constellation (i.e., Constellation thinks constellation X is open, but none of the projects are). I haven't taken much action here yet in part because it seems like a non-serious issue that could be a real time-sink, and also because it seems easy to rush down the wrong path.
It's probably possible to use some events and start making heuristics for whether to mark a constellation open or closed, but the definitions seem a little slippery once you look at them up close:
I added the notion of "open" constellations as a first step towards making Constellation's internal state more transparent via menus, and to avoid presenting silly menu options (like showing the option to open a constellation that is already open).
It's possible that this was the mistake here, and that the change should be to do away with the notion of a constellation itself being open or closed. It might ultimately yield a simpler and more transparent plugin if we treat each constellation more as a set of commands (open these projects if they are closed; close these projects if they are open). In this model, instead of introducing more transparency by tracking and exposing state, transparency would just mean exposing the effect of the sets of commands (this command would open these 4 projects, but they're all already open; this command would close these 3 projects, but only this 1 is open).
The text was updated successfully, but these errors were encountered: