When we actually want to attach the root view in window-bootstrap.coffee, we call `window.attachRootView(path)` instead of calling `window.startup(path)`. Having `startup` called automatically means we can be sure any code we add there runs in every environment (including benchmark and specs). This is where we do things like setup the global keymap, parse text mate bundles and themes, and establish the window close handler. Any globals other than the root view that we want to be available in all environments should be established here. Right now that's just the keymap, but soon I want to add a global pasteboard.
Previously this data was only sent to the done
handlers and so commands such as SelectAllMatchesInProject
were not displaying all the results when the result size
was large.
If we're pasting multiple lines starting inside an already existing line, we never want to auto indent. We should just take its existing indentation level. Also, we strip the leading whitespace off the first line we're inserting, assuming it's already being represented by the indentation of the line we're onto which we're appending it.
Also, when some lines are *less* indented than the first line, it might not be possible to outdent them as far as they originally were relative to the first line, so we do as much as possible.
Certain events call `abortKeyBinding` to opt out of handling certain keybindings. Snippets does this with tab for example. If it's not a situation where it's appropriate to go to the next tab stop, we let the next binding be triggered, which could insert a tab, for example. But when we trigger events from the event palette, there *is* no next binding. Having a no-op function helps in this situation.
This is at the moment a bit redundant, since you're already in the EventPalette when you see this. But we intend `@command` to communicate intent in the codebase, and its may also end up being used in other ways later.
For now, we auto-generate the documentation string by humanizing the event name. In the future, we may provide the option to provide more documentation, such as info about any arguments to the event, extended documentation, etc.
Also, auto-generate human readable event name in editor. This is a good example of how we could do this automatically for some kind of `onCommand`, `command`, `onInteractiveEvent` method that combines the event name, documentation string, and handler in one shot.
