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.
* Open the dev tools console
* Call `atom.beginTracing()`
* Do stuff
* Call `atom.endTracing()`
* Save the file somewhere
* Open `about:tracing` in chrome and load the file
* Inspect away!
This communicates back to the browser process to display the confirmation, then the browser replies to the message with the index of the clicked button.
Move the saving of serialized root view data to window.coffee. The window.startup method looks for window state on the atom object and instantiates the root view with that if it is present.