This is a temporary fix, it just stores compiled scripts in memory. It
doesn't speed up the app start since the scripts need to be compiled
once. Here are some numbers.
#file load
pre: 1.5 seconds
post: 0.25 seconds
#spec load
pre: 5.4 seconds
post: 0.36 seconds
Rename FileSystemHelper-contentsOfDirectoryAtPath… to -listFilesAtPath to make it clear that we're only listing files, not subdirectories. This is a fairly special purpose method but it saves us from calling back into objective-c a ton of times to filter them in JS, and makes bringing up the file finder ~2x as fast.
Converting from JS-cocoa wrapper values for every element in the array appears to be very slow. Here we construct native JS datatypes and it's much faster. This is very messy and leaky and needs to be cleaned up if we want to keep it.
Every menu item is created with a path (File > Save). The functions are stored in a hash from (menu item path -> action) on the window. When an AtomMenuItem is selected, it looks up the action on the current window based on its path.
This method removes any AtomMenuItems that aren't marked as 'global'. It ignores menu items that aren't instances of our custom subclass. This is needed by specs to clear any menu items added during tests. It will also be needed when a window loses focus and we want to remove any non-global menus associated with the window.
Move refresh handling to keyDown: method on AtomController. Eliminate custom handleInputEvent method.
NSApplication-sendEvent calls performKeyEquivalents on keydown events. Here I override sendEvent for keydown and forward the event to its window. This allows the web view to receive Command-H etc without key equivalents interfering. If the web view short-circuits the event, then the key equivalent will not be invoked. But it can let the event pass through and it ends up invoking the key equivalent anyway via a mechanism I don't fully understand. Apparently Cocoa tries to execute key equivalents after the web view finishes with the event? But it works great.
