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

Use atom.packages.hasActivatedInitialPackages #515

merged 1 commit into from Oct 28, 2017


None yet
1 participant

50Wliu commented Oct 28, 2017


  • Filling out the template is required. Any pull request that does not include enough information to be reviewed in a timely manner may be closed at the maintainers' discretion.
  • All new code requires tests to ensure against regressions

Description of the Change

I assume that the point of the atom.workspace? check was to try to wait until Atom was done loading before checking for text editors. However, the workspace may be loaded before text editors are deserialized. Therefore I rely on atom.packages.hasActivatedInitialPackages, which is the same thing that would happen if atom.workspace did not exist. This means that when reloading or closing/reopening Atom with a Markdown Preview open, the preview will continue to live update as it can find its existing editor. Before, it would become orphaned and rely on the backup file system events instead (due to atom.workspace.getTextEditors() being an empty array on startup).

Alternate Designs

Relying on package activation seems a bit weird. However, there doesn't seem to be a way to get whether the workspace has fully loaded or not, so this seems like a good alternative.


Less cases of unnecessary preview orphanage.

Possible Drawbacks


Applicable Issues


I wasn't able to test for this because I had to globally spy on atom.packages.hasActivatedInitialPackages, and also because the only way to truly test this would be to simulate an entire Atom restart.

Use atom.packages.hasActivatedInitialPackages
atom.workspace? is unreliable

@50Wliu 50Wliu merged commit ac08ed6 into master Oct 28, 2017

2 checks passed

continuous-integration/appveyor/pr AppVeyor build succeeded
continuous-integration/travis-ci/pr The Travis CI build passed

@50Wliu 50Wliu deleted the wl-view-deserialization branch Oct 28, 2017

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