The requiring of a package's main module is now decoupled from package
activation. Non-deferred packages will always be required before the
panes are deserialized. This allows the package to register any
deserializers for objects displayed in the panes.
Deferred packages can contain a 'deferredDeserializers' array in their
package.cson. If we attempt to deserialize an object with a deserializer
in the list, the package's main module will be required first so it has
a chance to register the deserializer. But the package still won't be
activated until an activation event occurs.
We may want to add an additional optional hook called 'load' which is
called at require time. We would not guarantee that the rootView
global would exist, but we could give the package a chance to register
deserializers etc. For now, registering deserializers is a side-effect
of requiring the package.
Modal dialogs can be presented while other modal dialogs are already
being displayed. Previously, dialogs were always displayed in the order
they were requested. But say you have two untitled buffers in a
pane and you close all items… You'll display prompt dialogs for both
buffers asking the user if they want to save. If the user answers yes
to the first dialog, they should see the path selection dialog before
they see the save prompt for the second buffer.
This commit uses a stack of queues to store deferred dialogs and allow
dialogs presented by the dismissal of another dialog to take precedence
over other pending dialogs.
Previously the user init script path was required before the
packages and user keymaps were loaded which could override
config and keymap settings set by the user init script path.
Packages that successfully built are now stored internally
so they can be quickly accessed on future calls instead of
returning an array of newly built packages on each call.
I've made requireStylesheet also check the loadedThemes for the
requiredStylesheet.
In the event that we have 2 stylesheets with the same name `editor.css`
and `editor.css` I want the `static/` directory stylesheet to be above
the userTheme stylesheet, so that proper cascading occurs. This commit
also adding class names to the styles.
TextMatePackage is only designed to load resources out of a TextMate
bundle. It's used only at load time, and from that point out we only
refer to our own global `syntax` data structure to access the data that
it loads.
These changes are mostly aesthetic in nature. I just thought it would
be a good idea to have theme loading be parallel to package loading as
much as possible. So I localized more logic on the `atom` global.
The `load` method on the superclass will provide a general template for
loading the package's resource. Each subclass will be responsible for
loading resources in a manner appropriate for the package type. There's
some initial progress on loading TextMate settings as scoped properties,
translating the TextMate scope selectors to CSS-style atom selectors.
This simplifies the loading of TextMate bundles in the spec and benchmark helpers. Since `loadBundle` was already implemented on `atom`, it made sense to move this logic here. Config is now more focused on its core job of handling configuration, not loading bundles.
The goal is that `loadPackage` will be the go-to place for loading all kinds of resources out of directories. `requireExtension` was only designed to load and activate extension modules.
