Activate package when deserializing #16100
Description of the Change
This PR unconditionally activates packages when a deserializer for that package is called. It also adds a new way of deferring package activation through the
To demonstrate how a package would benefit from this PR, consider a package that listens to the opener
There could be another key added to deserializers stating whether or not that deserializer should activate the package.
Why Should This Be In Core?
Deserializing happens in core.
Deserializing, openers, and deferred activation techniques can be used together.
Perhaps there are some deserializers that don't need the package to be activated? In which case this will slow down Atom's load time unnecessarily.
I think this is a great change. The
I'm wondering if this will break any assumptions that packages would previously have made regarding the timing of the call to
/cc @atom/maintainers Thoughts? Is it ok to change the timing in this way? If not, should we just attach the workspace element to the DOM before we do any deserialization?
This is good news: now the Atom code is more consistent and it's much easier to re-format the code to follow the codestyle (now you only need to run
This change caused conflicts on your PR that we have automatically solved, hope you don't mind