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

Ensure that new editors get unique ids #16455

Merged
merged 4 commits into from Dec 27, 2017

Conversation

Projects
None yet
2 participants
@fordhurley
Copy link
Contributor

fordhurley commented Dec 27, 2017

This restores the behavior from when TextEditor was written in Coffeescript and extended the Model class.

Description of the Change

With this change, editors opened after restoring the window state will get assigned IDs starting from max(editor IDs) + 1.

Alternate Designs

An alternative could be to select the lowest available unique ID. This would require a more complicated ID generator, but is certainly possible if a more dense ID space is desirable.

Why Should This Be In Core?

Assuming that editor IDs are supposed to be unique, this is a bug in core.

Benefits

Packages that look up editor instances by ID will be able to resolve to the correct editor.

Possible Drawbacks

I'm not aware of any drawbacks.

Applicable Issues

Fixes #16454.

Ensure that new editors get unique ids
This restores the behavior from when TextEditor was written in
coffeescript, and extended the Model class.
@maxbrunsfeld

This comment has been minimized.

Copy link
Contributor

maxbrunsfeld commented Dec 27, 2017

Thanks for fixing this. Could you add a test?

@fordhurley

This comment has been minimized.

Copy link
Contributor

fordhurley commented Dec 27, 2017

I'm not very familiar with writing jasmine tests, but I gave it a shot. If someone more experienced could provide guidance, I'd be happy to expand this a bit. I would personally prefer a test that actually checks for uniqueness of all IDs after initializing the workspace with a mixture of deserialized and "fresh" editors. The test I wrote is more a test of the exact bug this PR fixes, than protection against future regressions. I confirmed that it fails before this fix and passes after, at least...

@maxbrunsfeld

This comment has been minimized.

Copy link
Contributor

maxbrunsfeld commented Dec 27, 2017

The test looks fine to me. I'll merge this if CI passes.

@maxbrunsfeld

This comment has been minimized.

Copy link
Contributor

maxbrunsfeld commented Dec 27, 2017

@fordhurley It looks like your new test if failing on our CI.

Avoid dependency on shared state
The test was passing only when run in isolation.
@fordhurley

This comment has been minimized.

Copy link
Contributor

fordhurley commented Dec 27, 2017

Yup, it passed only when run in isolation (atom --test spec/text-editor-spec.js). I just took another stab at it.

@maxbrunsfeld maxbrunsfeld merged commit 3482f8f into atom:master Dec 27, 2017

3 checks passed

ci/circleci Your tests passed on CircleCI!
Details
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@maxbrunsfeld

This comment has been minimized.

Copy link
Contributor

maxbrunsfeld commented Dec 27, 2017

Thanks @fordhurley!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment