Skip to content
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

State inconsistencies created by sublime or other plugins #1

Open
abathur opened this issue Apr 9, 2018 · 0 comments
Open

State inconsistencies created by sublime or other plugins #1

abathur opened this issue Apr 9, 2018 · 0 comments

Comments

@abathur
Copy link
Owner

abathur commented Apr 9, 2018

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant